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Chapter  1 

Introduction 


This  document  provides  readers  with  the  meims  to  evsJuate  various  X.500  products  and  make 
informed  choices  as  to  which  available  products  best  match  the  reqmrements  of  their  organizations. 

This  document  is  aimed  at  procurement  officials,  systems  administration  staff  and  others  involved 
in  the  process  of  obtaining  or  recommending  X.500  products  for  use  in  their  organizations. 

At  the  time  of  writing,  the  1994  Edition  of  the  X.500/Directory  standard,  Reference  [1],  has  been 
finalized,  and  a  nimiber  of  1994  conformemt  products  should  be  driving  in  the  msirketplace  within 
the  foreseeable  future  (though  few  if  any  are  currently  avedlable). 

At  the  s£ime  time,  the  requirement  for  a  standardized,  intelligent,  distributed  database  system  is 
increasingly  being  felt  in  organizations  large  and  small.  The  initial  requirement  is  usually  for  a 
name-to-address  mapping  tool  for  X.400  electronic  m«dl,  but  as  new  applications  continue  to  be 
deployed,  such  as  Electronic  Data  Interchange  (EDI),  the  Directory  is  rapidly  becoming  a  pivotal 
information  storage  and  retrieved  medium. 

Given  that  an  organization  has  identified  the  need  for  some  X.500/Directory  functionzJity,  in  the 
form  of  clients  and/or  servers,  the  question  becomes  one  of  how  best  to  select  a  product  (or 
combination  of  products)  which  offers  an  array  of  features  which  best  match  the  organization's 
requirements. 

This  document  has  the  following  structure.  In  Chapter  2  a  brief  tutoried  on  the  X.500/Directory 
standcird  is  presented,  the  purpose  of  which  is  to  introduce  the  various  terms  and  concepts  associated 
with  the  Directory.  Directory  entries  and  their  structure  are  described,  followed  by  the  hiereirchical 
organization  of  the  Directory  information,  and  the  rules  governing  this  organization  (the  Directory 
Schema);  the  distributed  operation  of  the  Directory  is  outlined;  finally,  security  models  and  the 
replication  of  Directory  information  are  described. 

Chapter  3  is  entitled  "Functional  EveJuation  of  X.500"and  contedns  two  broad  sections.  Section 
3.1  details  a  list  of  standard  Directory  functions  that  a  purchaser  should  require  of  any  Directory 
product,  since  they  axe  mcindated  in  the  Directory  stfindard.  Such  functions  range  from  the  obvious 
(e.g.,  does  the  product  enable  the  user  to  perform  a  read  operation)  to  the  less  obvious  (e.g.,  does 
the  product  enable  the  user  to  specify  that  replicated  information  is  imsatisfactory  in  response 
to  a  given  operation).  In  short,  this  section  deeds  with  the  product's  conformance  to  the  X.500 
standard  (Reference  [1])  eind  related  docimients,  such  as  the  Industry/ Government  Open  Systems 
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Specification  (IGOSS)  (Reference  [11])  and  the  Stable  Implementation  Agreements  from  the  Open 
Systems  Environment  Implementors'  Workshop  (OIW)  (Reference  [12]). 

A  product  may  conform  to  the  letter  of  a  standard  and  amy  associated  implementor  agreements, 
Application  Progrsimming  Interfaces  (APIs),  etc.,  yet  still  be  cumbersome  to  use,  time  consimiing 
to  master,  and  resource-intensive  in  maintenance  and  administration,  to  name  just  a  few  potential 
pitfalls.  Section  3.2  suggests  a  list  of  features  which,  while  not  mandated  in  any  standard,  aie 
desirable  in  a  Directory  product  simply  because  they  increase  the  ease  of  use,  mainteucince,  etc.,  of 
the  product,  and  thus  increase  its  overaill  usefulness. 

Chapter  4  details  how  to  apply  the  information  set  out  in  the  Functional  Evaluation  Chapter  in 
a  practical  assessment  of  an  X.500  product,  and  contains  some  suggestions  as  to  how  to  decide 
on  which  aspects  of  the  X.500/Directory  system  are  importzint  to  the  organization  in  question.  In 
Chapter  4  a  measure  methodology  is  developed  which  enables  a  meeiningful  compeirison  between 
products,  and  thus  permits  the  user  to  firrive  at  an  informed  decision  as  to  which  product  to  select. 
This  section  is  entitled  "Performance  Evaluation  of  X.500  Products." 

1.1  Acknowledgments 

The  author  wishes  to  thank  Csirol  A.  Edgair  of  the  National  Institute  of  Standards  and  Technology 
who  assisted  in  the  editing  and  the  preparation  of  the  text  for  publication.  Miss  Edgar's  unfailing 
support  in  both  the  technical  and  editorial  review  of  this  document  was  extremely  helpful. 


Chapter  2 

An  Introduction  to  X.500(1994) 


2.1  Overview 

2.1.1    What  is  the  X.500  Directory  ? 

In  essence  the  Directory^  is  a  distributed  database,  capable  of  storing  information  about  people  sind 
objects  in  veirious  nodes  or  servers  distributed  across  a  network.  It  is  these  servers,  acting  in  concert, 
which  provide  the  potentially  global  access  to  information  made  possible  by  X.500  technology  (see 
fig.  2.1). 

Distributing  information  in  this  manner  has  various  advantages  over  the  conventional  method  of 
centralizing  information  storage,  for  example: 

•  The  information  is  kept  "close"  to  those  people  or  processes  which  are  most  likely  to  make 
most  frequent  use  of  it  aind  are  most  likely  to  be  responsible  for  keeping  it  up-to-date  -  this 
is  likely  to  reduce  access  time  find  network  costs,  and  increase  the  likelihood  of  the  accuracy 
of  the  stored  information; 

•  Since  the  information  is  distributed  across  several  (possibly  hundreds,  thousands,  or  even 
more)  servers,  the  impact  of  a  given  server  becoming  inactive,  for  whatever  reason,  is  only  to 
make  imavailable  the  information  for  which  that  server  is  responsible,  rather  thsin  bringing 
down  the  entire  database,  as  would  be  the  case  if  a  centredized  server  were  to  go  down; 

•  The  Directory  has  the  capacity  to  grow  indefinitely  in  size  find  storage  capacity  through  the 
simple  addition  of  new  nodes.  Such  growth  might  be  achievable  but  would  be  less  practical 
with  a  centralized  system; 

•  The  Directory  offers  the  opportunity  to  unify  information  resources  across  the  globe,  as 
opposed  to  the  insularity  which  tends  to  occiu:  when  orgeinizations  rely  on  proprietary,  cen- 
tralized databases. 

The  physical  location  of  the  accessed  information  is  transparent  to  the  user.  The  Directory  possesses 
the  necessary  knowledge  to  locate  requested  information,  reg£irdless  of  where  the  information  might 

^Throughout  this  text  the  teims  "X.500"  and  "The  Directory"  will  be  used  synonymously. 
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Figure  2.1:  The  Directory  -  Conceptual  View. 


be  on  the  network.  To  access  the  Directory,  the  user  will  usually  interface  to  the  server  closest  to 
him/her,  and  all  information  received  will  usually  appeeir  as  if  it  came  directly  from  that  server. 
Prom  the  user's  point  of  view,  the  Directory  behaves  exactly  as  if  the  user  was  accessing  a  centrsdized 
server.'^ 

2.1.2    How  does  the  Directory  work? 

The  Directory  user  (person  or  process)  accesses  the  Directory  via  a  client  process  known  as  a 
Directory  User  Agent,  or  DUA  (see  fig.  2.2).  The  DUA  interfaces  with  the  Directory  using  a 
standard  protocol  between  itself  and  one  of  the  Directory  servers,  termed  Directory  System  Agents, 
or  DSAs.  Usually  the  DSA  contacted  would  be  the  one  closest,  in  terms  of  connection  cost  or 
organizational  tiffiliation,  to  the  Directory  User  Agent. 

The  DSAs  making  up  the  Directory  ailso  commimicate  via  a  standard  protocol  which  embodies  a 
set  of  operations  which  may  be  performed  by  the  Directory  (e.g.,  retrieving  information,  adding 
information,  etc.).  Each  DSA  knows  how  to  contact  one  or  more  additional  DSAs  (at  least  one). 
This  is  the  mechanism  through  which  a  Directory  request  can  be  propagated  through  the  system: 
if  a  pjirticuleir  DSA  is  unable  to  satisfy  a  request,  the  request  is  forwarded  to  another  DSA  which 
is  more  likely  to  have  the  necessary  information,  and  so  on. 

^It  is  envisioned  that  most  Directory  users  will  not  be  people,  but  application  processes.  Nevertheless,  the  uniform 
interface  provided  by  the  Directory  is  still  desirable 
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Figure  2.2:  Various  applications  interface  to  the  Directory  via  Directory  User  Agents. 
2.1.3    About  this  tutorial 

The  tutorial  provides  fin  introduction  to  the  following  aspects  of  X.500: 

•  Entries.  The  imiversfJ  unit  of  information  storage  in  the  Directory. 

•  Attributes.  The  constituent  elements  of  entries. 

•  Object  Classes.  An  identifier  signifying  the  class  of  entries  to  which  a  given  entry  belongs. 
Entries  are  grouped  into  classes  on  the  basis  of  shfired  properties. 

•  Schema.  The  set  of  rules  and  assertions  governing  where  ajo.  entry  may  be  placed  within  the 
Directory,  how  it  shall  be  neimed,  and  what  information  it  may  contsdn. 

•  Services.  The  set  of  services  which  enable  the  user  to  manipulate  information  held  by  the 
Directory. 

•  Distributed  Operation.  The  mechanisms  by  which  multiple  septate  servers  are  linked 
together  to  form  a  single  Directory  entity. 

•  Seciurity.  The  methods  by  which  the  Directory  protects  the  information  it  holds  from  unau- 
thorized access. 

•  Replication.  The  meeins  by  which  information  held  by  a  DSA  may  be  copied  to  one  or  more 
other  DSAs  in  order  to  increase  efficiency  and  decrease  access  time. 

•  Operational  Bindings.  Bilatered  agreements  made  between  DSAs  to  provide  various  ser- 
vices to  one  ainother.  These  agreements  fire  usually  used  for  the  creation  find  administration 
of  Shadowing  agreements. 
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2.1.4    Tutorial  Objective  and  Constraints 


1.  The  aim  of  this  tutorial  is  to  give  a  good  working  knowledge  of  the  principles  of  the  Directory 
-  there  is  no  emphasis  on  technical  details,  though  references  to  the  Standard  docimient  are 
given  when  appropriate. 

2.  It  is  impossible,  in  a  brief  tutoriaJ  such  as  this,  to  cover  in  detail  aU  the  material  emd  concepts 
presented  in  the  X.500(1994)  Stemdard.  The  Standard  document  itself  approaches  the  thick- 
ness of  a  telephone  book!  For  greater  detail,  it  is  suggested  the  reader  considt  the  Standard 
itself,  Reference  [1].  Also,  there  are  a  variety  of  commercially  available  texts  which  cover  the 
material  in  greater  depth. 

3.  This  tutorial  will  be  published  both  sep£irately  as  a  self-contained  tutorial  and  as  part  of 
NIST's  X.500  Evaluation  Criit(2e/me«  publication. 

2.2  Entries 

The  entry  is  the  fundamental  xmit  of  information  in  the  Directory.  That  is  to  say,  £ill  information 
stored  in  the  Directory  is  stored  ia  the  form  of  entries,  each  of  which  is  uniquely  Ueimed  and 
represents  one  of  three  things: 

1.  An  object  in  the  real  world  -  the  bulk  of  the  entries  in  the  Directory  are  of  this  type,  termed 
an  object  entry] 

2.  An  alternative  name  for  bld.  object  entry.  This  type  of  entry  is  termed  £in  alias  entry,  and  is 
also  uniquely  named;  or 

3.  A  collection  of  information  used  to  meet  administrative  needs  of  the  Directory.  Such  an  entry 
is  termed  a  subentry. 

The  unique  neiming  of  entries  is  described  ia  Section  2.5. 
2.2.1    Object  Entries 

Typically,  when  the  term  "entry"  or  "Directory  entry"  is  used,  it  refers  to  an  object  entry,  though 
all  entries  are  structured  in  the  same  manner. 

All  Directory  entries  are  made  up  of  a  collection  of  attributes  (described  ia  sec.  2.3),  each  of  which 
describes  a  peirticular  quality  or  aspect  of  the  object  represented  by  the  entry.  Figure  2.3  displays 
a  schematic  of  an  object  entry  together  with  some  of  its  constituent  attributes  and  their  associated 
values.  The  figure  represents  a  hypothetical  object  entry  which  has  an  attribute  of  type  Telephone 
Number  with  a  wahie  of  303-498  1633,  indicating  that  the  real  world  person  ia  question  has  the 
telephone  number  303-498  1633.  In  this  regard,  £in  entry  may  be  likened  to  a  database  record,  and 
ein  attribute  to  a  field  of  that  record. 

Initieilly  it  was  envisioned  that  the  entries  in  the  Directory  would  contsdn  information  relating 
largely  to  data  commimications  devices  and  applications,  but  increasingly  it  is  being  thought  of  as 
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Attributes 


Entry 


Type 


Common  Name 


Value 


Ronald  A.  Lester 


Telephone  Number 


303-498  1633 


E-mail  Address 

rlester@usda.gov 

/G=Ron/S=Lester/0=USDA/C=US 

Street  Address 

United  States  Department  of 

Agriculture 

3825  E.  Mulberry  Street 

Fort  Collins 

Colorado,  80524 

Figure  2.3:  The  structure  of  a  Directory  entry. 

a  general  purpose  repository  for  all  kinds  of  information,  ranging  from  personnel  records  through 
automotive  parts  inventories  to  on-line  telephone  directories  and  database  services.  That  having 
been  said,  it  seems  that  the  most  import£int  role  for  X.500  in  the  forseeable  future  is  as  an  enabling 
technology  for  data  commtmications,  especially  electronic  mail. 

2.2.2    Alias  Entries 


An  alias  entry  contains  only  one  user  attribute,  the  VfJue  of  which  is  the  xmique  name  of  an  object 
entry.  Alias  entries  are  thus  used  to  provide  alternative  names  for  object  entries.  This  can  be  useful 
in  the  case  when  the  actual  name  of  an  entry  is  cumber somely  long.  The  use  of  aliases  will  become 
clecirer  in  Section  2.5  on  the  Directory  Schema. 

When  an  sJias  entry  is  encoimtered  by  one  of  the  Directory  services  (decribed  in  sec.  2.6)  as  the 
name  of  an  entry,  the  aliasedEntryName  attribute  is  read,  the  target  object  of  the  operation  is  reset 
to  the  name  it  contains,  and  processing  continues  as  if  the  aliasedEntryNtime  had  been  supplied  as 
the  originid  entry  name  to  the  service.  This  process  is  known  as  alias  dereferencing. 

Aliases  may  point  to  object  entries  or  other  alias  entries,  but  they  must  edways  be  leaf  entries,  i.e., 
they  are  not  permitted  to  have  subordinate  entries. 
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2.2.3  Subentries 


A  subentry  is  used  for  internal  administration  within  the  Directory  architecture.  It  contziins  infor- 
mation used  by  the  Directory  in  various  administrative  functions.  For  example,  collective  attributes, 
described  in  Section  2.3,  are  stored  in  subentries,  along  with  accounting  and  access  control  infor- 
mation for  the  entries  in  the  vicinity  of  the  subentry. 

2.2.4    Entry  Collections 

An  entry  collection  may  be  formed  when  any  set  of  entries  shaxe  properties  or  characteristics  in 
common.  Usually  when  this  is  the  case,  the  common  information  may  be  stored  once  in  a  collective 
attribute  (see  sec.  2.3)  rather  than  being  stored  many  times,  once  in  each  individual  entry. 

2.3  Attributes 

The  Directory  Staindeird  specifies  and  defines  a  set  of  commonly  used  attribute  types  which  c£in  be 
augmented  by  various  implementor  bodies,  by  vendors  or  by  users.  The  mecheinism  for  attribute 
definition  is  the  ATTRIBUTE  information  object  class,  which  is  given  in  Clause  12.4.6  of  Reference 
[3]. 

The  Directory  attribute  holds  information  regarding  a  pjirticulair  quality  or  characteristic  of  an 
object  represented  by  a  Directory  entry,  and  has  two  principal  components:  a  type  indicator,  and 
a  set  of  values.  Figure  2.3  in  Section  2.2  shows  how  attribute  types  and  values  are  combined  into 
a  Directory  entry.  Also  associated  with  each  attribute  are  a  set  of  matching  rules,  which  indicate 
whether  the  attribute  is  to  have  a  single  or  multiple  values.  The  attribute  may  also  contain 
administrative  data. 

2.3.1  Attribute  Type 

The  attribute  type  is  a  unique  identifier  which  has  both  a  semantic  and  a  syntactic  function.  The 
semantic  function  is  to  indicate  what  purpose  the  information  contfiined  in  the  attribute  serves. 
For  example,  is  it  a  telephone  nimiber,  a  network  address,  a  social  security  nimiber,  a  nickname, 
eind  so  on.  The  syntactic  function  is  to  indicate  how  the  attribute  value  should  be  parsed  in  order 
to  accurately  retrieve  the  information  it  contains. 

2.3.2  Attribute  Values 

The  attribute  value  is  where  the  attribute's  information  is  held.  As  mentioned  above,  the  parsing 
and  interpretation  of  the  attribute  value  is  determined  by  the  attribute  type. 

2.3.3  Matching  Rules 

Each  attribute  has  associated  with  it  a  set  of  matching  rides  which  determine  how  values  of  the 
attribute  may  be  matched  against  other  values.  For  ex£imple,  an  entry  may  be  of  interest  if  it  has 
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an  attribute  representing  a  telephone  number,  one  of  whose  values  is  equal  to  301-555  8937.  In 
this  case,  it  would  be  desirable  to  permit  the  comparison  of  telephone  number  attribute  values  for 
equality  with  presented  values.  Such  a  comptirison  is  dictated  by  the  equality  matching  rule  for 
the  attribute  in  question.  The  other  matching  rules  which  may  be  included  in  the  attribute  are 
rules  for  ordering  matchy  to  determine  whether  a  stored  quantity  is  greater  or  less  than  a  presented 
quantity;  and  substrings  match,  which  enables  presented  substrings  to  be  picked  out  of  stored  string 
values. 


2.3.4    Attribute  Type  Hierarchies 

When  defining  attributes  in  the  Directory,  it  is  possible,  though  not  necesseiry,  to  create  an  attribute 
hierarchy,  by  defining  groups  of  attributes  of  a  genertd  nature  and  then  defining  subtypes  of  these 
attributes  to  hold  more  refined  or  detailed  information  of  a  similar  natxire.  These  latter  attribute 
types  can,  in  turn,  serve  as  super  types  for  another  level  of  attribute  sub-typing. 

As  an  example,  suppose  we  define  an  extremely  genercJ  attribute  type,  which  we  caU  Address  (see 
fig.  2.4). 


address 


Figure  2.4:  The  base  attribute  of  the  Address  attribute  hierarchy. 

Address  can  mean  virtuedly  any  point  of  contact  with  some  person  or  entity,  and  we  reflect  this 
by  creating  several  subtypes  of  our  base  attribute:  Postal  Address,  Electronic  Mail  Address,  and 
Telephone  Number.  Thus  we  have  a  two  tier  hierarchy,  as  shown  in  Figure  2.5. 


Figure  2.5:  The  Address  attribute  hierarchy,  showing  three  subtypes  of  the  base  type. 

Of  course,  each  of  the  three  subtypes  is  also  fairly  genersil,  for  example,  we  might  wish  to  define 
individual  attribute  subtypes  under  Electronic  Mail  Address  for  X.4OO  Address,  Simple  Mail  Trans- 
port Protocol  (SMTP)  Address  and  cc:Mail  Address,  which  leads  to  the  three  tier  hierarchy  shown 
in  Figure  2.6. 

The  useful  aspect  of  attribute  type  hierarchies  is  that  they  offer  the  opportunity  to  examine  Direc- 
tory information  at  different  levels  of  detail.  When  an  attribute  type  is  requested  in  an  information 
retrievjil  request,^  attributes  of  that  type  together  with  all  its  subtypes  aie  returned.  Thus,  in  om 
example,  if  the  attribute  type  Address  is  requested,  the  Directory  wiU  return  aU  attributes  of  types 


'Information  retrieval  services  are  discussed  in  Section  2.6 
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Figure  2.6:  The  Address  attribute  hierarchy,  showing  subtypes  of  electronic  mail  address. 

Address,  Postal  Address,  Electronic  Mail  Address,  Telephone  Number,  X.4OO  Address,  SMTP  Ad- 
dress and  cc:Mail  Address.  If  Electronic  Mail  Address  is  requested,  all  attributes  of  types  Electronic 
Mail  Address,  X.4OO  Address,  SMTP  Address  and  cc:Mail  Address  will  be  returned.  And  finzdly, 
if  only  attributes  of  type  X.4OO  Address  are  desired,  that  is  the  attribute  type  which  shoidd  be 
specified  in  the  information  retrieval  request. 

,2.3.5    Collective  Attributes 

Collective  attributes  serve  as  repositories  for  information  common  to  £ill  entries  in  £in  entry  collection 
(see  sec.  2.2).  For  exeimple,  if  aH  entries  in  a  group  share  the  s£ime  telephone  number  (as  may 
be  the  case  for  the  members  of  a  household),  the  information  might  be  stored  in  a  collective 
attribute  residing  in  a  Directory  subentry  close  to  the  object  entries  making  up  the  entry  collection. 
One  advantage  of  storing  information  in  this  way  is  that,  if  it  becomes  necessary  to  change  the 
information,  this  need  be  done  only  once  for  all  the  members  of  the  collective,  rather  than  once  for 
each  member. 

The  information  held  in  collective  attributes  appesirs  as  if  it  is  part  of  the  information  held  in  any 
entry  in  the  entry  collection  when  that  entry  is  retrieved  using  any  of  the  Directory  interrogation 
services,  but  modification  must  take  place  through  the  subentry  where  the  information  is  actually 
held. 

2.4    Object  Classes 

Directory  object  classes  are  used  principsJly  to  distinguish  between  entries  representing  different 
types  of  objects.  Each  Directory  entry  must  belong  to  at  least  one  object  class,  eind  contain  an 
attribute,  the  V£ilue(s)  of  which  indicate(s)  the  object  class(es)  to  which  the  entry  belongs.  Following 
from  this  descriptive  function,  the  entry's  object  class  serves  severed  specific  functions  within  the 
Directory: 

•  It  governs  the  attributes  the  entry  contains  (see  sec.  2.4.1); 
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•  It  governs  the  position  the  entry  may  take  in  the  Directory  structure  (see  sec.  2.4.2);  and 

•  It  governs  the  administrative  policy  associated  with  the  entry  (see  sec.  2.4.3). 

As  is  the  case  for  Directory  attributes,  object  classes  may  be  defined  in  international  standards,  by 
other  stfindards  or  implementor  bodies,  by  vendors,  or  by  users.  The  mechanism  for  object  class 
definition  is  described  in  Clause  12.3.3  of  Reference  [3]. 

2.4.1  Entry  Attributes 

The  object  class  of  an  entry  dictates  which  attributes  the  entry  may  contain.*  In  fact,  it  specifies 
a  set  of  attributes  the  entry  must  contiiin,  along  with  a  further  set  which  the  entry  may  contain. 
No  additional  attributes  £ire  permitted.  See  Section  2.4.5  for  additional  information  on  object  class 
types  and  entry  composition. 

As  axL  exzunple,  suppose  we  define  an  object  class.  Used  Car,  to  represent  a  used  car.  We  might 
conclude  that  certeiin  information  about  a  vehicle  was  indispensable  in  entries  of  this  object  class, 
so  we  would  insist  that  they  MUST  CONTAIN  attributes  indicating  the  cm's  Make/Model,  Year 
of  Manufacture  and  Original  Mileage.  On  the  other  hiind,  there  £ire  several  attributes  the  car  might 
have  which  we  consider  of  lesser  importance,  but  nonetheless  desirable,  so  we  stipulate  that  entries 
of  this  object  class  MAY  CONTAIN  attributes  indicating  the  vehicle's  color,  engine  size,  list  of 
options,  availability  of  service  record,  and  so  on.  We  have  now  described  the  composition  of  entries 
used  in  the  Directory  to  describe  used  cars. 

2.4.2  Entry  Position 

The  object  class  identifier  attribute  of  the  entry  is  used  by  the  Directory  to  ensure  that  the  entry  is 
not  placed  inappropriately  within  the  Directory  database.  The  structure  of  the  Directory  database 
eind  the  placement  of  entries  therein  is  described  in  Section  2.5. 

2.4.3  Administrative  Policy 

Various  aspects  of  administrative  policy  may  be  associated  only  with  entries  of  particular  object 
classes.  The  Directory  Administrative  Model  is  described  in  Clause  4  of  Reference  [3]. 

2.4.4  Object  Class  Inheritance 

Object  classes  may  be  created  by  decleiring  them  to  be  subclasses  of  existing  object  classes.  In  this 
case,  the  new  object  class  inherits  aU  the  attributes  of  an  existing  object  class,  its  superclass,  and 
has  the  opportimity  to  add  further  attributes. 

To  extend  our  example  above,  suppose  we  have  an  organization,  Dave's  Used  Cars,  for  which  the 
existing  Used  Car  object  class  is  useful  but  not  sufficient.  A  new  object  class,  Dave's  Used  Car, 
may  be  derived  from  the  existing  one  by  declaring  it  a  SUBCLASS  OF  Used  Car,  and  further 

*See  also  Section  2.5  for  the  influence  of  Directory  Content  Rules  on  the  contents  of  entries. 
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stipulating  that  it  MUST  CONTAIN  attributes  indicating,  say,  a  local  stock  number  and  date  of 
arrival,  and  that  it  MAY  CONTAIN  attributes  indicating  the  vehicle's  source  and  perhaps  blue 
book  value.  Thus,  entries  of  object  class  Dave's  Used  Cm  will  contain  all  the  attributes  of  the 
Used  Car  object  class,  plus  those  additioneilly  specified  by  Dave. 

Each  entry  in  the  Directory  must  contain  an  attribute  indicating  the  object  classes  to  which  it 
belongs.  This  is  because,  by  definition,  each  object  class  is  a  subclass  of  a  special  object  class 
known  simply  as  top,  which  indicates  that  all  attributes  MUST  CONTAIN  such  an  attribute. 
This  attribute  holds  the  unique  object  class  identifier  for  the  object  class  to  which  the  entry  belongs, 
in  addition  to  the  corresponding  identifiers  for  all  the  entry's  superclasses.  Thus,  an  entry  belonging 
to  a  given  class  also  belongs  to  all  the  superclasses  of  that  class.  This  set  of  superclasses,  from  the 
entry  up  to  top,  is  know  as  the  object  class'  superclass  chain. 

Returning  to  our  example,  an  entry  of  class  Dave's  Used  Car  also  belongs  to  class  Used  Car, 
and  so  on,  back  up  the  chain  of  whatever  superclasses  Used  Car  might  have. 

One  important  effect  of  this  object  class  inheritance  is  that  if  an  information  retrieval  request  is 
made  based  on  the  object  class  of  the  entry,  all  entries  of  that  class  and  all  its  subclasses  will  be 
returned. 

2.4.5    Types  of  Object  Class 

Object  classes  may  be  subdivided  into  three  types:  abstract,  structural,  and  auxiliary.  So  far,  this 
section  focused  on  structurjil  object  classes.  The  two  other  classes  can  be  stunmarized  as  follows: 

2.4.5.1  Abstract  Object  Class 

An  abstract  object  class  is  an  object  class  which  is  defined  purely  for  the  purpose  of  serving  as  a 
superclass  or  template  for  other  (structured)  object  classes.  It  is  a  way  of  conveniently  collecting 
together  a  set  of  attributes  which  it  is  known  wiU  be  common  to  a  set  of  structural  object  classes, 
in  order  that  these  classes  may  be  derived  as  subclasses  of  the  abstract  class  rather  than  being 
defined  from  scratch.  For  example,  an  abstract  object  class  Person  can  be  defined  with  address, 
phone  nimiber.  Date  of  Birth  (DOB),  etc.,  things  everyone  has.  Then  it  is  possible  to  subclass 
a  structural  object  class  like  NISTPerson,  with  additional  attributes  of  grade,  s£ileiry,  personnel 
number,  etc. 

Note  that  an  entry  may  not  belong  to  an  abstract  object  class. 

2.4.5.2  Auxiliary  Object  Class 

Each  entry,  while  belonging  to  only  a  single  structural  object  class,  may  belong  to  zero  or  more 
auxiliary  object  classes.  Auxiliary  object  classes  serve  as  a  means  to  provide  multiple  inheritance  to 
Directory  entries,  that  is  to  say,  to  combine  the  attributes  from  two  or  more  superclass  cheiins  into 
a  single  entry.  This  is  useful  in  the  case  where  a  common  group  of  attributes  is  desired  in  entries 
from  various  object  class  hierarchies.  For  example,  the  attributes  of  an  object  class  Bank  Account 
Holder  might  be  included  into  entries  of  structural  object  classes  as  varied  as  Residential  Person, 
Personnel  Manager,  Business  Organization  and  Government  Department. 
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2.5    The  Directory  Schema 


2.5.1  Overview 

The  Directory  Schema  constitutes  the  £r£miework  within  which  Directory  information  is  stored.  It 
consists  of  a  set  of  rules  and  definitions  which  define  the  naming  of  entries,  the  content  of  attributes 
£ind  entries,  the  structure  of  the  Directory  as  a  whole,  eind  the  hierairchic£j  relationships  between 
entries. 

The  Schema  comprises  the  following  components  (in  accordance  with  Recommendation  X.501 
Clause  12.2,  Reference  [3]): 

•  Name  Form  definitions,  which  describe  how  Directory  entries  should  be  named; 

•  Directory  Information  Tree  (DIT)  Structure  Rules,  which  define  hierarchical  relation- 
ships between  entries  of  different  object  classes; 

•  Content  Rule  definitions,  which  allow  the  inclusion  in  entries  of  attributes  not  indicated  in 
the  entries'  structural  object  classes; 

•  Object  Class  definitions  -  see  Section  2.4; 

•  Attribute  Type  definitions  -  see  Section  2.3;  £ind 

•  Matching  Rule  definitions  -  see  Section  2.3. 


2.5.2    Naming  of  Directory  Entries 
2.5.2.1    Directory  Names 

Each  entry  in  the  Directory  is  identified  by  at  least  one^  unique  nsune,  csiUed  the  entry's  Distin- 
guished Name  or  DN.  The  DN  is  formed  in  the  following  fashion: 


1.  The  Directory  Information  Base  (DEB)  is  organized  into  a  tree-shaped  hierarchy,  the  DIT, 
in  which  each  entry  has  exactly  one  superior  entry  but  may  have  mfiny  subordinate  entries. 
This  organization  is  illustrated  in  Figure  2.7. 

Clearly,  each  superior  entry  may  have  many  subordinates,  so  the  entry  may  be  one  of  many 
siblings  at  the  same  level  in  the  tree. 

2.  Each  entry  contains  at  least  one  attribute  value  which  is  designated  as  the  entry's  nzime 
at  that  level,  i.e.,  relative  to  eiU  its  siblings.  This  name,  known  as  the  entry's  Relative 
Distinguished  Name  or  RDN,  must  be  unique  among  all  the  entry's  siblings.  There  are 
times  when  it  is  necessary  to  select  more  than  one  attribute  veilue  in  order  to  distinguish 
between  siblings,  and  other  times  when  it  is  desirable  to  select  more  than  one  attribute  yahie 
for  the  sake  of  cleirity: 


Siurname  :  Lester 


OR 


Surname  :  Lester,  Given  Name  :  Ronald 


'Aliases  may  be  used  to  piovide  alternative  names. 
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Figure  2.7:  The  basic  structure  of  the  Directory  Information  Tree. 


3.  The  unique  name  of  the  entry,  its  Distinguished  Name  or  DN,  is  formed  by  the  concate- 
nation of  the  RDN  of  the  entry  with  those  of  each  of  its  superiors,  from  the  top  of  the  DIT 
on  down  to  the  entry. 


'Organization 


Government  ^ 


f  Org. 

Unit  1 

USDA 

f  Org.  Unit 


NIST  , 


[  Org. 

Unit  ] 

i  DH 

HS  J 

Name 

Lester,  Ron 


Name  ~ 

Tebbutt,  John 


Name 

Trus,  Steve 


Name 

Cooley,  Bob 


Figure  2.8:  An  example  of  a  Directory  Information  Tree. 

The  following  example  applies  these  niles  to  the  hypothetical  DIT  three  levels  deep  shown  in  Figure 
2.8.  The  exeimple  concerns  the  n£iming  of  organizations,  orgainizationed  tmits,  and  people  connected 
with  those  orgemizationeJ  units. 

The  example  contciins  eight  entries,  each  with  its  own  Distinguished  Name: 


1.  /Organization  (0)  =  Government 

2.  /O  =  Government /Organizational  Unit  (OU)  =  USDA 

3.  /O  =  Government/OU  =  NIST 
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4. 

10 

=  Government /OU  = 

DHHS 

5. 

10 

=  Government /OU  = 

USDA/Name  (CN,  for  "Common  Name") 

6. 

10 

=  Government /OU  = 

NIST/CN  = 

Tebbutt,  John 

7. 

10 

=  Government /OU  =: 

NIST/CN  = 

Trus,  Steve 

8. 

10 

=  Government /OU  = 

DHHS/CN  = 

:  Cooley,  Bob 

This  exctmple  also  illustrates  the  use  of  three  standard  attributes  commonly  used  for  the  naming  of 
entries:  Organization  Neune  (O),  Organizational  Unit  Name  (OU)  and  Common  Name  (CN).  These 
attributes,  together  with  the  other  standard  attributes  (i.e.,  those  defined  by  the  X.500  Stfindard, 
specifically  Recommendation  X.520),  can  be  fotmd  in  Reference  [7]. 

2.6.2.2    Name  Form  Definition 

A  Name  Form  specifies  which  attribute  types  within  an  object  class  may  form  pjirt  of  the  RDN  of 
entries  belonging  to  that  class.  This  carries  the  implication  that  there  may  be  certain  attributes 
in  an  entry  which  should  not  be  used  as  part  of  that  entry's  RDN.  For  exiunple,  in  an  entry 
representing  a  person's  health  record,  the  use  of  the  person's  weight  or  last  white  blood  cell  count 
as  part  of  the  RDN  woidd  in  most  cases  be  of  little  utility,  whereas  the  use  of  the  person's  name, 
patient  niunber,  Socied  Security  number,  etc.,  would  be  a  far  more  natural  and  practical  choice. 
The  netme  form  definition  is  used  to  enforce  such  constrtdnts  within  the  Directory. 

Another  implication  of  the  name  form  definition  is  that  at  least  one  of  the  mzindatory  attributes 
of  the  object  class  must  be  specified  as  the  naming  attribute  for  the  object  class,  if  entries  of  that 
class  are  to  have  names  (which,  of  course,  they  must). 

Note  also  that  potentially  several  name  forms  may  be  defined  for  each  object  class,  allowing  for 
entries  belonging  to  that  class  to  be  named  in  different  ways,  according  to  their  placement  in  the 
DIT  and  the  accompanying  DIT  structure  rules  (see  sec.  2.5.3). 

The  formal  method  of  Name  Form  Specification  is  given  in  Clause  12.6.3  of  Reference  [3]. 
2.5.3    Directory  Information  Tree  Structure  Rules 

The  placement  of  entries  within  a  portion  of  the  DIT  is  governed  by  rides  set  out  by  the  responsible 
authority,  known  as  DIT  Structure  Rules.  Each  entry  in  the  Directory  contains  fin  attribute  of  Type 
governingStructureRule,  which  holds  the  structure  rule  that  governs  the  possible  placement  of 
the  entry.  The  entry  may  oidy  be  placed  in  a  portion  of  the  DIT  if  the  Directory  schema  holds  a 
DIT  structiire  rule  which  matches  that  held  in  the  entry. 

The  DIT  structtire  rule  consists  of  3  psirts: 

1.  A  unique  identifier; 

2.  A  naxae  form  identifier,  which  specifies  the  Ueime  form  that  entries  governed  by  this  structure 
rule  will  take; 
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3.  A  list  of  superior  structiire  rule  identifiers,  which  denote  where  in  the  DIT  the  entry  may  be 
placed,  i.e.,  the  classes  of  entry  to  which  it  is  subordinate. 


2.5.4    Directory  Information  Tree  Content  Rules 

The  content  of  an  entry,  in  terms  of  the  attributes  it  contains,  is  regulated  primfiriiy  by  the  entry's 
structural  and  auxilifiry  object  classes  (see  sec.  2.4).  However,  additionsJ  contents  may  be  specified 
by  the  definition  of  a  DIT  Content  Rule  associated  with  the  entry's  structural  object  class. 

A  DIT  content  rule  specifies  the  following  (in  accordiince  with  Reference  [3],  Clause  12.7.1): 


•  The  identifier  of  the  structural  object  class  to  which  it  applies; 

•  The  identifiers  of  the  axixiliary  object  classes  permitted  in  entries  governed  by  the  rule  (op- 
tioned); 

•  The  identifiers  of  the  mandatory  attributes  required  for  entries  governed  by  the  content  rule, 
in  addition  to  those  mandated  in  the  structural  and  auxilifiry  object  classes  (optional); 

•  The  identifiers  of  the  optional  attributes  required  for  entries  governed  by  the  content  rule,  in 
addition  to  those  neimed  in  the  structural  and  auxiliary  object  classes  (optional);  and 

•  A  list  of  identifiers  of  optional  attributes  from  the  entry's  structural  and  auxilieiry  object 
classes  which  the  content  rule  precludes  from  appearing  in  entries  governed  by  the  rule  (op- 
tional). 


Note  that,  imlike  the  characteristics  of  an  object  class,  those  of  a  DIT  content  rule  Me  not  inherited 
by  any  subclasses  of  the  object  class  to  which  it  applies. 

The  DIT  content  rules  axe  thus  useful  in  the  following  ways: 


•  They  permit  the  modification  of  an  object  class  at  a  particular  level  in  the  object  class 
hierarchy,  while  avoiding  the  inclusion  of  the  modifications  into  the  object  class  chedn; 

•  They  permit  the  exclusion  of  certain  optional  attributes  from  entries  of  a  given  object  class 
without  modifying  the  object  class  itself;  £ind 

•  They  sillow  the  inclusion  of  individual  attributes  into  entries,  without  reference  to  other  object 
classes. 


2.6  Services 


This  section  describes  the  set  of  services  available  to  users  of  the  Directory  for  the  retrieval  £ind 
manipulation  of  Directory  information.  With  these  services,  the  user  Cein  retrieve  information,  add 
new  information,  browse  through  the  DIB,  delete  information  and  move  information  around  within 
the  Directory  Information  Base. 
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Note  that  these  services  are  performed  on  behfilf  of  the  user^  by  the  Directory  System  Agents 
(DSAs)  which  administer  the  Directory  Information  Base.  Access  to  the  Directory  is  via  the 
Directory  User  Agents  (DUAs),  which  may  present  these  services  in  a  variety  of  ways,  depending 
upon  the  DUA  product  in  use. 

Protocols.  Directory  User  Agents  and  DSAs  communicate  with  each  other  using  steindardized 
communications  protocols.  The  Directory  Access  Protocol,  or  DAP,  is  used  by  DUAs  to 
communicate  with  DSAs,  and  vice  versa.  The  more  complex  Directory  Systems  Protocol,  or 
DSP,  is  used  by  DSAs  to  communicate  with  each  other.  It  contains  information  not  found  in  the 
DAP,  such  as  trace  information,  which  enables  DSAs  to  monitor  the  progress  of  an  operation. 

Application  Contexts.  An  Application  Context  is  a  group  of  functions  or  operations  required 
in  order  to  provide  a  ptirticular  service  or  set  of  services.  The  Directory  standard  specifies  several 
Application  Contexts.  The  directoryAccessAC  Application  Context  describes  the  fonctioneility 
necessMy  to  provide  the  services  associated  with  the  DAP,  while  the  directory  System  AC  Ap- 
plication Context  acts  in  a  similar  fashion  for  the  Directory  System  Protocol.  The  remaining 
Application  Contexts  are  concerned  with  Shadowing  or  Replication  of  data  in  the  Directory,  and 
Directory  Operational  Binding  Management.^ 

The  outcome  of  a  Directory  operation  takes  one  of  three  forms: 

•  Result.  A  Directory  result  contains  either  (a)  the  requested  information  from  the  indicated 
entry  or  entries,  in  the  case  of  the  Read,  List  and  Search  operations,  or  (b)  £in  indication 
of  whether  the  operation  was  successful  or  not  in  the  case  of  the  rem«dning  operations; 

•  Referral.  If  the  DSA  holding  the  teirget  entry  of  the  operation  could  not  be  reached  for 
some  reason  (e.g.,  the  chainingProhibited  service  control  was  set),  then  £in  indication  of 
the  address  of  the  DSA  which  is  logicfilly  the  next  closest  to  the  tcirget  entry's  DSA  is  returned 
to  the  Directory  User  Agent; 

•  Error.  If  the  entry  could  not  be  located,  a  potential  violation  of  the  schema  was  detected,  a 
possible  security  breach  was  detected,  or  any  of  a  number  of  other  conditions  prohibiting  the 
completion  of  the  operation  occurred,  this  is  conveyed  to  the  DUA  in  the  form  of  a  Directory 
Error.® 

The  Directory  offers  the  following  basic  services,  each  of  which  will  subsequently  be  reviewed  in 
greater  detail.  It  should  be  emphasized  that,  in  isolation,  these  services  provide  only  the  building 
blocks  from  which  more  sophisticated,  value-added  user  services  may  be  constructed. 

•  Read.  Retrieve  the  information  contained  in  an  entry,  as  specified  by  its  Distinguished  Name; 

•  Compare.  Compare  a  user-supplied  attribute  value  against  one  held  in  an  entry,  as  specified 
by  its  Distinguished  Nfime; 

'Person  or  application  process. 

^See  Sections  2.10  and  2.9  for  more  on  Shadowing/Replication  and  Operational  Bindings  in  the  Directory. 
*See  Reference  [4]  for  a  fuller  explanation  of  Directory  Errors. 
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•  List.  List  the  subordinate  entries  of  an  entry,  as  specified  by  its  Distinguished  Nsime; 

•  Search.  Search  through  all  the  subordinate  entries  of  an  entry,  as  specified  by  its  Distin- 
guished Name,  returning  those  entries  which  match  specified  criteria; 

•  Add  Entry.  Add  a  new  entry  to  the  Directory  Information  Base,  specifying  the  new  entry's 
name  and  contents; 

•  Remove  Entry.  Delete  an  entry  from  the  Directory  Liformation  Base,  as  specified  by  its 
Distinguished  Name; 

•  Modify  Entry.  Modify  the  contents  of  a  Directory  entry,  as  specified  by  its  Distinguished 
Nsmae,  specifying  the  desired  modifications; 

c  Modify  Distinguished  Name.  Change  the  Relative  Distinguished  Nsime  of  an  entry,  as 
specified  by  its  Distinguished  name,  or  move  it  to  a  new  superior  in  the  Directory  Liformation 
Tree,  or  both. 

2.6.1  Read 

K  users  know  the  DN  of  £in  entry  contfdning  information  they  wish  to  retrieve,  the  Read  service  may 
be  used  to  obtain  the  entry's  contents  or  a  subset  thereof.  The  user  needs  to  specify  the  following: 


•  The  DN  of  the  entry; 

•  The  parts  of  the  entry  to  be  retrieved.  The  user  is  able  to  select  certain  attributes  or  simply  to 
request  the  entire  contents  of  the  entry.  For  example,  a  telephone  directory  application  might 
obtain  John  Smith's  telephone  number  from  his  personnel  record  entry  simply  by  requesting 
his  telephone  number  attribute  (there  is  no  reason  for  a  telephone  directory  application  to 
retrieve  the  entire  entry)  while  a  personnel  application  would  need  access  to  the  entire  entry;® 

•  An  optional  request  to  the  Directory  to  return  the  privileges  she/he  has  to  modify  the  entry 
and  its  attributes. ^° 


2.6.2  Compare 


The  Compare  service  is  used  to  compare  a  value  against  an  attribute  vfilue  in  an  entry  whose  name 
the  user  knows.  It  returns  a  true  or  false  response  -  true  if  the  values  matched,  false  if  they  didn't. 
Such  a  service  c£in  be  used  for  password  checking  applications  or  for  other  applications  where  the 
creator  or  owner  of  a  Directory  entry  does  not  wish  to  disclose  information  directly,  but  is  willing 
to  confirm  information  to  individujJs  who  eilready  have  access  to  it.  The  user  specifies: 


•  The  DN  of  the  entry;  «ind 

•  The  value  to  be  compared. 

°In  fact,  the  telephone  application  can  be  actively  prevented  horn  retrieving  information  other  than  the  telephone 
number  attribute  using  access  control  -  this  will  be  discussed  in  Section  2.8. 
^°Thi8  is  also  tied  into  access  control  -  see  Section  2.8. 
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2.6.3  List 


This  service  is  used  primarily  to  browse  the  Directory  Information  Tree.  With  it,  a  user  can  request 
a  listing  of  the  immediate  subordinates  of  an  entry,  whose  name  she/he  supplies.  This  process  may 
be  repeated  using  the  name  of  one  of  the  subordinates  returned,  and  so  on.  The  user  may  thus 
better  pictorialize  the  part  of  the  DIT  in  which  she/he  is  interested.  This  process  c£in  also  be  used 
as  a  primitive  search  function.  For  exfunple,  if  a  user  w£ints  to  look  up  Bob  Walsh's  project  code, 
and  she/he  knows  Bob  works  in  Accounts,  but  is  not  qmte  sure  of  Bob's  DN,  she/he  cam  list  out 
the  subordinates  of  the  Accoimts  Department's  entry,  and  find  Bob's  entry  that  way.  This  service 
requires  the  user  to  specify  two  items: 

•  The  DN  of  the  entry  whose  subordinates  Me  to  be  listed;  and 

•  An  optiontd  indication  as  to  whether  the  results  are  to  be  returned  in  a  paged  fashion. 
2.6.4  Search 

The  most  powerful  of  the  Directory  information  retrieval  services,  Search,  enables  the  user  to  extract 
from  a  portion  of  the  DIB  those  entries  which  conform  to  a  set  of  criteria  she/he  has  specified, 
returning  selected  information  from  each  entry.  In  essence,  the  Search  operation  identifies  a  set  of 
entries  which  satisfy  the  user's  requirements,  and  then  reads  each  entry  in  much  the  same  way  as 
is  done  by  the  Read  service. 

The  sttirting  point  for  the  search  is  an  entry  whose  DN  the  user  supplies.  The  search  criteria 
axe  supplied  in  a  standard  logical  format,  using  the  operators  AND,  OR  and  NOT,  £ind  c£in  be 
grouped.  They  sJso  depend  on  the  matching  rules  discussed  earlier  (see  sec.  2.3).^^ 

Returning  to  our  earlier  example  of  Dave's  Used  Car  business,  suppose  that  one  of  Dave's  customers 
is  looking  for  a  1989  Corvette,  but  will  settle  for  a  Ceimaro,  as  long  as  it  is  a  1990  or  newer  model  and 
the  price  is  less  than  $10,000.  For  the  benefit  of  the  Seeirch  operation,  these  criteria  are  expressed 
as  follows: 

((MAKE  EQUAL  TO  Corvette)  AND  (YEAR  EQUAL  TO  1989)) 

OR 

((MAKE  EQUAL  TO  Camaro) 
AND 

(YEAR  GREATER  THAN  1989) 
AND 

(PRICE  LESS  THAN  10,000)) 

^^The  means  by  which  the  user  actually  commumcates  the  search  criteria  to  the  Directory  via  the  DUA  will  depend 
upon  the  product  in  use,  so  it  is  only  possible  to  describe  the  logical  framework  here. 
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Since  both  cars  happen  to  be  Chevrolets  in  this  instance,  the  DN  of  the  starting  entry  might  look 
something  like: 

/C=US/0=Dave'8  Used  Car8/Category=Stock/Manufacturer=Chevrolet^^ 

The  Search  service  allows  the  user  to  specify  which  attributes  of  the  matched  entries  should  be 
returned,  just  as  for  the  Read  service  (see  sec.  2.6.1)  so,  to  continue  our  example,  Dave  might  pull 
up  the  mileage  and  stock  number  of  each  car  returned  by  the  Search. 

2.6.5    Add  Entry 

The  Add  Entry  service  allows  the  user  to  create  a  new  entry  in  the  Directory  Information  Base. 
The  new  entry  may  only  be  created  as  a  leaf  entry,  i.e.,  it  must  be  added  as  a  subordinate  of  an 
existing  leaf  entry,  as  opposed  to  being  inserted  into  the  DIT  between  existing  entries.  Subordinate 
entries  to  the  new  entry  may  be  added  later. 

In  order  to  create  a  new  entry,  the  user  should  specify: 

•  The  DN  of  the  entry; 

•  The  set  of  attributes  which  will  make  up  the  new  entry  (see  sees.  2.2  and  2.3);  and 

•  The  DSA  upon  which  the  entry  should  reside,  if  this  is  different  from  the  DSA  holding  the 
entry's  superior  entry  (see  sec.  2.7  for  more  information  on  the  distribution  of  information 
between  Directory  System  Agents). 

The  Directory  performs  a  series  of  checks  on  the  information  in  the  Add  Entry  request: 

•  Does  the  superior  entry  exist? 

•  If  so,  does  the  user  have  the  authority  to  create  a  new  entry  at  this  position  in  the  DIT  (see 
sec.  2.8  for  information  on  DIT  Seciirity  policy)? 

•  If  so,  is  the  new  entry  allowed  as  a  subordinate  to  the  superior  entry,  based  on  their  respective 
object  classes? 

•  If  so,  are  the  attributes  specified  in  the  Add  Entry  request  consistent  with  the  supplied  object 
class  £ind  any  applicable  DIT  Content  Riiles? 

•  If  so,  the  entry  is  added,  otherwise  the  request  is  rejected. 

The  Add  Entry  service  is  the  prim£iry  meeins  by  which  information  is  added  to  the  Directory  once 
the  initial  bidk  load  is  done.^'* 

'^^For  the  sake  of  this  example,  Category  and  Manufacturer  aie  Object  Classes  assumed  to  have  been  created 
by  Dave  for  the  classification  of  the  objects  in  his  database. 

^'The  means  by  which  the  initial  bulk  load  are  done  will  depend  on  the  particular  X.500  product  in  use. 
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2.6.6    Remove  Entry 


In  order  to  delete  an  entry  from  the  DIB,  the  user  employs  the  Remove  Entry  service  of  the 
Directory.  As  with  the  Add  Entry  service,  this  service  may  only  be  applied  to  leaf  entries  of  the 
DIT  -  it  is  not  possible  to  delete  a  non-leaf  entry,  leaving  a  number  of  prior  subordinates  dangling. 

All  that  is  required  in  order  to  delete  an  entry  is  the  entry's  DN.  If  the  entry  exists,  is  a  leaf  entry, 
and  the  user  has  sufficient  security  access  rights  (see  sec.  2.8  for  information  on  DIT  Security 
policy),  then  the  entry  will  be  deleted. 

2.6.7  Modify  Entry 

Information  held  in  the  Directory  can  be  updated  through  use  of  the  Modify  Entry  service.  This 
service  may  be  applied  to  any  entry  in  the  DEB,  subject  to  access  control  considerations  (see  sec. 
2.8  for  information  on  DIT  Security  policy),  £ind  permits  multiple  simuIt2ineous  modifications  to 
be  made.  The  user  must  specify  the  following: 

•  The  DN  of  the  entry  to  be  modified; 

•  The  set  of  modifications  to  be  made  to  the  entry,  which  may  comprise  any  number  of  the 
following  modification  types: 

—  Add  an  attribute; 

—  Delete  an  attribute; 

—  Add  one  or  more  values  to  an  existing  attribute; 

—  Delete  one  or  more  values  from  an  existing  attribute. 

Note  that  the  replacement  of  vedues  in  an  attribute  can  be  achieved  by  a  combination  of  delete 
value  £ind  add  vjilue  instructions  in  the  same  request.  In  fact,  most  user  interfaces  shotild  hide  this 
entirely  from  the  user  and  simply  offer  a  Replace  Value?  option. 

2.6.8  Modify  DN 

The  Modify  DN  service  is  used  to  ch£inge  the  Distinguished  Neime  of  a  Directory  entry.  Since  the 
DN  of  an  entry  determines  its  position  in  the  DIT,  this  service  may  be  used  either  to  change  the 
position  of  an  entry  in  the  DIT,  or  simply  to  change  the  RDN  of  the  entry,  leaving  its  position  in 
the  DIT  unaff"ected. 

Two  simple  exeimples  of  the  use  of  the  Modify  DN  operation  might  be  a  name  change: 

/0=Accotmts 
might  become 
/0=Accoimts  and  Finzmces 
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or  a  structural  reorganization: 

/0=GMC/Location=Detroit/0=Accounts 
might  become 
/  0=GMC/Location=Louisville/0= Accounts. 
In  order  to  employ  this  service,  the  following  information  is  necessary: 

•  The  original  DN  of  the  entry; 

•  The  new  RDN  to  be  given  to  the  entry,  if  the  Distinguished  Name  is  being  changed; 

•  Whether  the  old  RDN  should  be  deleted;  and 

•  The  DN  of  the  entry's  new  superior  entry,  if  the  entry  is  to  be  moved  in  the  Directory 
Information  Tree. 

Note  that  security  and  schema  nile  enforcement  are  carried  out  by  the  Directory,  so  that  if  the 
renaming  or  repositioning  of  the  entry  woidd  be  in  violation  of  these  considerations,  the  operation 
will  not  be  cfirried  out  (see  sees.  2.5  £ind  2.8). 

2.6.9    Common  Arguments 

Each  Directory  operation  carries  with  it  a  parameter  set  known  as  Common  Arguments. The 
elements  making  up  the  Common  Arguments  specify  various  elements  of  the  operation  request 
which  are  relatively  stable  throughout  the  duration  of  a  Directory  interface  session.  They  are 
referred  to  as  Common  Arguments  because  they  are  common  to  all  operations.  Some  of  the 
more  important  elements  of  the  Common  Arguments,  from  the  user's  point  of  view,  are  listed 
here: 

•  Service  Controls.  The  Service  Controls  element  is  itself  a  set  of  parameters  which  allow 
the  user  to  specify,  for  instance,  whether  information  from  a  replicated  copy  of  an  entry  will 
suffice  in  lieu  of  information  tfkken  directly  from  the  master  copy;  whether  chaining  between 
DSAs  is  preferred  or  prohibited;^^  the  priority  of  the  request;  the  time  limit  within  which 
completion  of  the  operation  is  required;  the  size  limit  of  any  operation  response,  and  so  on. 

•  Security  Parameters.  This  element  contains  any  security-related  information  connected 
with  the  request. 

•  Requestor.  This  is  the  Distinguished  Name  of  the  originator  of  the  Directory  operation. 

^*See  Reference  [4],  Clause  7.3  for  more  on  Common  Arguments, 
^'^see  Section  2.7  for  more  on  chaining. 
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2.7    Distributed  Operation 


So  far  in  this  text,  mention  has  been  made  several  times  of  the  fact  that  the  Directory  is  made  up 
of  several  Directory  Systems  Agents  (DSAs),  each  of  which  holds  a  portion  of  the  overall  Directory 
Information  Base.^^  This  section  deals  with  how  the  DSAs  cooperate  with  one  another  in  order  to 
provide  users  with  transparent  access  to  the  data  stored  in  the  Directory  Information  Base. 

2.7.1    Relationship  of  DSAs  to  the  Directory  Information  Tree 

Each  DSA  represents  an  Administrative  Authority,  which  extends  over  one  or  more  ptirts  of  the 
Directory  Information  Tree.  The  individual  pwts  of  the  DIT  which  fall  under  the  authority  of  a 
DSA  are  referred  to  as  Naming  Contexts. 

2.7.1.1    Naming  Contexts 


Naming  Context  B 


<||||)  Object  Entry  Subentry  Alias  Entry 

Figure  2.9:  An  example  DIT  showing  different  Naming  Contexts. 

The  DIT  can  be  broken  up  into  subtrees,^^  each  of  which  begins  with  a  particular  entry  as  its  root 
and  contains  all  the  subordinate  entries  of  that  entry,  down  to  a  certain  level.  Such  a  chunk  of  the 
DIT  is  referred  to  as  a  naming  context,  and  represents  the  way  the  DIT  is  broken  up  for  storage  in 
the  various  DSAs  comprising  the  Directory.  Figure  2.9  illustrates  how  a  Directory  Information  Tree 
may  be  broken  up  into  various  naming  contexts.  Note  that  the  lower  limit  of  a  naming  context 
may  be  made  up  of  leaf  or  non-leaf  entries.  If  one  of  the  lowest  level  entries  is  a  non-leaf,  this 

^'There  is  a  degenetate  case  where  all  the  data  aie  stoied  in  a  single  DSA,  in  which  case  the  Diiectoiy  becomes  a 
centralized,  as  opposed  to  a  distributed,  database,  and  the  information  in  this  section  is  not  relevant. 
^^A  subtree  is  simply  a  branch  of  the  Directory  Information  Tree. 
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implies  that  it  has  at  least  one  subordinate  entry,  which  must  be  in  another  naming  context.  Such 
a  neiming  context  is  referred  to  as  a  subordinate  naming  context  as  a  result,  with  the  previous 
naming  context  being  referred  to  as  its  superior  naming  context.  In  Figure  2.9,  contexts  B  and 
C  are  subordinate  to  context  A,  which  is  their  superior.  The  DN  of  the  root  entry  of  the  naming 
context  is  called  the  Context  Prefix. 

2.7.1.2    Relationships  Between  Directory  System  Agents 


Figure  2.10:  An  example  DIT  showing  the  mapping  of  different  naming  contexts  into  administrative 
domains. 

The  relationships  between  DSAs,  and  thus,  between  the  Administrative  Management  Domains 
(ADMDs)  they  represent  are  dictated  by  the  relationships  between  the  ntiming  contexts  they  ad- 
minister. It  should  be  noted  that  any  given  DSA  may  administer  any  number  of  ntiming  contexts 
from  anywhere  in  the  DIT,  but  the  root  entry  of  each  nztming  context  will  usually  have  a  supe- 
rior entry  in  another  naming  context,  which  in  turn  wiU  often  reside  on  another  Directory  System 
Agent. In  such  a  situation,  eind  for  that  particidar  neiming  context,  the  DSA/ADMD  holding 
the  superior  nsiming  context  is  said  to  be  the  superior  DSA/ADMD,  while  that  holding  the  sub- 
ordinate naming  context  is  described  as  the  subordinate  Directory  System  Agent /Administrative 
Management  Dom£iin.  Figure  2.10  shows  an  exfimple  DIT  broken  up  into  five  ADMDs  (i.e.,  spread 
across  five  DSAs).  In  this  exeimple,  it  cfin  be  seen  that  ADMD  1  is  superior  to  ADMD  2,  ADMD 
3  and  ADMD  5;  ADMD  2  is  superior  to  ADMD  3;  and  ADMD  5  is  superior  to  ADMD  4.  The 
superior  ADMD  to  ADMD  1  is  not  shown. 

^'This  applies  to  all  naming  contexts  except  the  so-called  "first  level"  or  "root"  naming  context,  which  has  the 
abstract  root  of  the  entire  DIT  as  its  root.  See  Clause  17.3  of  [3]  for  further  detail. 
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2.7.2  Knowledge 


The  DSAs  making  up  the  Directory  are  able  to  function  as  a  single  unit  because  each  one  has  at 
least  a  Tninimum  amount  of  knowledge  about  DSAs  which  hold  external  naming  contexts.  The 
absolute  minimum  amotmt  of  knowledge  a  DSA  must  possess  is  the  address  of  a  DSA  which  holds 
a  naming  context  which  is  superior  to  all  the  naming  contexts  held  by  the  DSA,  and  the  addresses 
of  all  DSAs  which  hold  naming  contexts  subordinate  to  those  held  by  the  Directory  System  Agent. 
Thus,  if  a  DSA  is  presented  with  a  request  concerning  a  Directory  entry,  it  knows  that  it  c£in  either 
process  the  request  itself,  because  it  holds  the  entry  in  one  of  its  own  naming  contexts,  or  that 
the  entry  exists  in  a  nsiming  context  subordinate  to  one  it  holds,  in  which  case  it  can  forwjird  the 
request  to  a  DSA  responsible  for  a  subordinate  naming  context  or,  if  it  has  no  idea  where  the  entry 
might  be,  as  a  last  resort  it  can  forward  the  request  to  a  DSA  holding  a  naming  context  nearer 
the  root  of  the  DIT,  in  the  knowledge  that  the  hierarchical  iirrangement  of  the  DIT  wUl  eventueJly 
direct  the  request  to  the  correct  Directory  System  Agent. 


ISR  to  superior... 
SR  to  B  for  <b> 
SR  to  C  for  <o 
NSSR  to  C  for  «i> 


A 


ISR  to  A  for  <a> 
CR  to  C  for  <d> 


A 


y^\^NatniDg  Context 


DSA  <a>  Naming  Context  ID 


ISR  =  Immediate  Superior  Reference;  SR  =  Subordinate  Reference; 
NSSR  =  Non-SpeciGc  Subordinate  Reference;  CR  =  Cross  Reference. 

Figure  2.11:  An  example  DSA  configuration  showing  the  knowledge  references  associated  with  the 
DIT  structure. 

The  types  of  knowledge  described  above  are  known  &s  Superior  (Knowledge)  References  sjid  Subor- 
dinate (Knowledge)  References,  respectively.  Other  types  of  knowledge  reference  exist,  which  may 
be  used  to  enhance  the  distributed  operation  of  the  Directory: 

•  Immediate  Superior  Reference.  This  is  a  knowledge  reference  to  a  DSA  which  holds  a 
naming  context  immediately  superior  to  one  held  by  the  DSA,  and  can  be  used  when  the 
DSA  recognizes  that  the  DN  of  the  target  entry  of  an  operation  matches  part  of  the  context 
prefix  of  a  naming  context  it  holds,  but  is  shorter; 
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•  Non-Specific  Subordinate  Reference.  This  is  a  reference  to  a  DSA  which  holds  a  naming 
context  subordinate  to  one  held  by  the  DSA,  the  context  prefix  of  which  is  not  known  by  the 
DSA  (in  contrast,  in  a  subordinate  reference  the  context  prefix  of  the  subordinate  naming 
context  is  known).  This  type  of  reference  is  used  in  the  same  way  as  a  subordinate  reference; 

•  Cross  Reference.  This  is  a  reference  which  may  point  to  a  DSA  holding  a  neiming  context 
anywhere  in  the  DIT,  and  is  used  to  optimize  the  time  taken  to  pinpoint  an  entry.  For 
instance,  if  a  DSA  frequently  receives  requests  pertaining  to  entries  in  a  particulzir  naming 
context  which  is  neither  subordinate  nor  superior  to  a  naming  context  it  holds,  it  my  be  wise 
to  set  up  a  cross  reference  to  the  DSA  holding  the  naming  context  in  question,  so  that  the 
requests  may  be  forweirded  there  immediately. 

Figure  2.11  shows  some  knowledge  references  which  might  be  associated  with  the  mapping  of  an 
example  DIT  onto  three  Directory  System  Agents.  The  DSA  A  holds  naming  context  A,  «ind  thus 
must  hold  Immediate  Subordinate  References  to  DSAs  B  and  C,  since  they  hold  nsiming  contexts 
B  and  C,  respectively,  each  of  which  is  immediately  subordinate  to  naming  context  A.  The  DSA  A 
eJso  holds  an  Immediate  Superior  Reference  to  an  imknown  superior  (unknown  only  because  it  is 
not  shown  in  the  example),  eind  a  Non-Specific  Subordinate  Reference  to  DSA  C  for  naming  context 
D.  Of  the  references  held  by  DSA  A,  only  the  last  one,  the  Non-Specific  Subordinate  Reference,  is 
optional,  and  will  have  been  included  to  increase  the  efficiency  of  DIT  traversal. 

The  DSAs  B  find  C  each  hold  Immediate  Superior  References  to  DSA  A,  since  DSA  A  holds  the 
superior  naming  context  to  neiming  contexts  B  and  C,  respectively.  The  DSAs  B  and  C  also  hold 
cross  references  to  each  other.  These  Cross  References  are  optionzd,  but  they  may  increase  Directory 
efficiency  by  enabling  each  of  these  DSAs  to  bypass  DSA  A  and  pass  information  requests  directly 
to  one  another  for  entries  residing  in  nsiming  contexts  they  hold.  For  example,  if  DSA  C  receives  a 
request  relating  to  an  entry  which  lies  in  naming  context  B,  using  the  Cross  Reference  it  can  pass 
the  request  directly  to  DSA  B,  whereas  the  alternative  would  be  to  pass  the  request  up  to  DSA  A 
and  rely  on  its  knowledge  of  naming  context  B's  location  in  order  to  complete  the  request.  Clearly 
this  latter  alternative  would  tend  to  increase  resource  utilization,  error  rates  and  processing  time 
for  the  request.  Note  that,  since  DSA  B  does  not  have  a  Cross  Reference  to  DSA  C  for  naming 
context  D,  any  requests  it  receives  for  entries  lying  in  n£iming  context  D  will  be  passed  up  through 
DSA  A.  This  emphasizes  that  a  Knowledge  Reference  of  any  kind  refers  to  a  naming  context  as 
well  as  the  DSA  which  administers  it. 

2.7.3    Knowledge  and  Efficiency 

The  retrieval  of  Directory  information  may  involve  the  intercoimection  of  several  Directory  System 
Agents.  In  such  a  chain  of  systems,  each  DSA  will  do  some  processing  before  initiating  a  connection 
to  the  next  DSA,  and  this  process  can  be  expected  to  be  time  consxmiing.  Just  how  time  consuming 
it  is  depends  on  the  quality  of  the  commxmications  links  between  the  systems,  the  quality  of  the 
remote  systems  themselves,  along  with  the  X.500  products  in  use  at  the  remote  sites,  and  to  a  Izirge 
degree  on  the  optimization  of  the  local  DSA  configuration.  With  appropriate  knowledge  references, 
the  number  of  DSA-DSA  hops  can  be  minimized,  and  the  processing  time  for  a  distributed  operation 
thus  reduced.  The  inclusion  of  such  knowledge  references  is  a  crucial  part  of  the  configuration  of 
the  local  DSA  £ind  adds  greatly  to  the  system's  intelligence. 
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2.8  Security 


Security  in  the  Directory  requires  two  separate  components:  authentication  of  Directory  users  to 
verify  their  identity,  and  access  control  procedures  to  prevent  unauthorized  access  to  Directory 
information.  While  security  is  of  paramotmt  importeince  in  the  Directory,  just  as  in  any  other  open 
application,  discussion  of  this  topic  can  become  lengthy  find  involved  and,  since  security  policy 
is  not  a  topic  xmique  to  the  Directory,  it  will  be  given  only  a  perfunctory  overview  here.  For  an 
excellent  and  detailed  explwation  of  authentication  practices,  the  reader  is  referred  to  Reference  [9], 
£ind  for  a  thorough  stmmiary  of  the  access  control  methods  available  to  Directory  administrators, 
see  Clause  15  of  Reference  [3]. 

2.8.1    User  Authentication 

The  pmrpose  of  user  authentication  is  to  verify  the  identity  of  a  Directory  user,  so  that  access 
to  Directory  information  can  be  granted  or  denied  with  a  high  level  of  confidence  that  the  user 
requesting  the  access  is  in  fact  who  she/he  claims  to  be. 

Two  authentication  schemes  are  described  for  the  Directory,  Simple  Authentication  and  Strong 
Authentication. 

2.8.1.1  Simple  Authentication 

The  simple  authentication  procedure  involves  passing  a  user's  name,  in  the  form  of  the  DN  of  the 
user's  Directory  entry,  £ind  a  password  to  the  Directory.  The  Directory  checks  for  an  entry  with  the 
supplied  DN  and,  if  such  an  entry  exists,  compeires  the  supplied  password  against  the  value  stored 
in  the  UserPassword  attribute  of  the  entry.  H  the  value  matches,  the  user  is  authenticated.  This 
method  offers  a  minimum  security  approach,  since  neither  the  user's  name  nor  the  password  are 
encrypted  or  encoded  in  any  way. 

Simple  authentication  can  be  made  somewhat  more  secure  by  using  a  one-way  hashing  function  on 
the  user's  n£ime  and  password  supplied  to  the  Directory.  This  function  involves  the  user's  name, 
password,  time  stamp,  and  a  collection  of  reindom  ntunbers. 

2.8.1.2  Strong  Authentication 

The  strong  authentication  scheme  adopted  by  the  Directory  stfindard  relies  on  the  use  of  a  public- 
key  crjrptosystem,  in  which  each  user  possesses  two  keys,  one  public  and  one  private,  the  latter  of 
which  is  known  only  to  the  user.  Each  of  these  keys  may  be  used  to  encipher  or  decipher  the  user's 
authentication  information,  in  a  complementary  fashion  (i.e.,  if  the  information  was  enciphered 
with  the  private  key,  it  must  be  deciphered  with  the  public  key,  and  vice  versa).  If  a  user's  public 
key  is  held  by  the  Directory,  then  it  can  be  used  to  confirm  the  user's  identity  if  the  user  submits 
his/her  authentication  information  encrypted  using  his/her  private  key. 
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2.8.2    Access  Control 

In  order  to  control  access  to  Directory  information,  the  DIB  is  viewed  as  a  collection  of  protected 
items: 

•  Entries; 

•  Attributes; 

•  Attribute  Values;  and 

•  Names. 

Each  protected  item  has  associated  with  it  a  set  of  permissions,  representing  the  access  rights  of 
users,  groups  of  users,  or  the  general  public.  These  permissions  are  further  broken  down  on  the 
basis  of  the  Directory  operations. 

The  permission  categories  associated  with  entries  (and  nsimes)  are: 

•  Read.  The  entry  contents  may  be  read  only  if  the  entry  is  explicitly  named  in  the  operation; 

•  Browse.  The  entry  contents  may  be  accessed  without  the  entry  being  explicitly  named  in 
the  operation; 

•  Add.  An  entry  may  be  created; 

•  Remove.  The  entry  may  be  deleted; 

•  Modify.  The  contents  of  the  entry  maybe  modified,  provided  that  appropriate  permissions 
exist  on  the  attribute  and  attribute  vidue  level; 

•  Rename.  The  entry's  RDN  may  be  changed; 

•  Disclose  On  Error.  The  entry's  name  may  be  disclosed  if  an  error  occurs; 

•  Export.  Permits  the  entry  to  be  moved  to  a  new  location  in  the  DIT,  using  the  ModifyDN 
operation  (see  sec.  2.6); 

•  Import.  Permits  an  entry  to  be  removed  from  another  location  and  placed  in  the  location 
where  the  permission  applies;  and 

•  Return  Distinguished  Name.  Allows  the  DN  of  the  entry  to  be  disclosed  in  £in  operation 
result. 

The  permissions  associated  with  attributes  and  attribute  vsJues  are  slightly  different  than  those  for 
entries: 

•  Compeure.  Attributes  and  values  may  be  compared  to  supplied  vcdues; 
^'See  Section  2.6  for  a  list  of  the  Directory  operations. 
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•  Read.  The  attribute  or  value  may  be  returned  in  response  to  a  read  or  search  operation; 

•  FilterMatch.  The  attribute  or  value  may  be  used  in  the  evaluation  of  a  search  filter  (see 
sec.  2.6); 

•  Add.  Permits  the  addition  of  an  attribute  or  value; 

•  Remove.  Permits  the  removed  of  an  attribute  with  till  its  values,  or  the  removal  of  a  single 
attribute  value;  and 

•  Disclose  On  Error.  Permits  the  presence  of  an  attribute  or  attribute  vjJue  to  be  disclosed 
in  case  of  error. 

For  each  permission  category,  each  protected  item  has  £in  indication  of  which  users  or  groups  of 
users  possess  that  permission  (or  whether  the  permission  is  publicly  avedlable).  Thus,  when  a 
user  requests  a  pfirticidar  operation,  the  Directory  locates  the  protected  item(s)  in  question  and 
ascertains  whether  the  user  has  permission  before  cfirrying  out  the  operation.  If  not,  then  the 
operation  is  not  carried  out  and  a  security  error  may  be  returned,  depending  on  the  disclosure 
permission  for  the  protected  item  in  question. 

2.9    Operational  Bindings 

An  Operational  Binding  is  the  formalization  of  £in  agreement  between  two  Directory  Administrations 
for  their  respective  DSAs  to  provide  services  to,  or  receive  services  from,  one  ainother  on  an  exclusive 
basis.  The  operational  binding  framework  is  deliberately  left  very  general,  so  that  it  can  serve  as 
the  frfimework  for  many  different  kinds  of  operational  binding  agreements  which  can  be  envisioned 
in  the  future.  For  the  time  being;  however,  the  principed  use  for  operational  bindings  is  the  setting 
up,  modification  and  termination  of  Shadowing  Agreements  (see  sec.  2.10). 

An  operational  binding  has  the  following  key  components: 

•  The  two  DSAs  between  which  the  binding  will  exist.  The  binding  may  be  symmetric,  with 
each  DSA  providing  the  same  set  of  services  and  having  the  same  role  in  the  management  of 
the  operationsd  binding,  or  asymmetric,  in  which  case  each  DSA  will  provide  different  services 
(e.g.,  as  in  the  Shadow  Supplier  and  Shadow  Consimier  in  the  Directory  Replication  model) 
jind  may  have  differing  roles  in  the  meinagement  of  the  operational  binding; 

•  An  agreement  describing  the  services  the  DSAs  will  provide  to  one  another.  This  agreement 
is  made  between  the  Administrative  Authorities  responsible  for  the  DSAs  involved,  perhaps 
as  a  legal  contract  or  inter-organizationad  memo; 

•  The  set  of  Directory  operations  to  be  used  by  the  DSAs  involved  to  carry  out  the  services 
defined  by  the  operational  binding.  These  operations  embody  the  content  of  the  operational 
binding  agreement  into  a  form  which  is  readily  machine  ihterpretable  and  can  thus  be  used  as 
the  basis  for  protocol  exchfmges  between  the  two  DSAs  within  the  context  of  the  operational 
binding; 

•  Operations  for  the  msinagement  of  the  operational  binding,  providing  for  its  establishment, 
modification  and  termination;  and 
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•  An  identifier  for  the  operational  binding  which  is  unique  between  the  two  DSAs,  such  that 
this  identifier,  plus  the  names  of  the  DSAs,  constitute  a  globally  iinique  identifier  for  the 
operational  binding. 

The  Directory  Standard  (Reference  [1])  establishes  a  fourth  protocol,  the  Directory  Operational 
Binding  Management  Protocol,  or  DOP,  to  furnish  Directory  operations  for  the  management  of 
operational  bindings.  The  protocol  defLaes  operations  for  the  establishment,  modification  and 
termination  of  an  operational  binding. 

To  illustrate  how  operational  bindings  £tre  used  in  the  setting  up  of  replication  agreements  between 
DSAs  (see  sec.  2.10)  suppose,  in  Figure  2.11  of  Section  2.7,  that  an  agreement  was  made  between 
the  Administrative  authorities  responsible  for  DSAs  B  and  C  stating  that  DSA  B  should  keep 
a  shadow  copy  of  naming  context  D,  to  be  updated  at  set  intervals.  Further  suppose  that  the 
meinagement  of  the  operational  binding  itself  is  to  be  symmetriced,  i.e.,  either  DSA  may  establish, 
terminate  or  modify  any  instance  of  the  binding. 

The  operationfJ  binding  agreement  is  specified  using  the  OPERATIONAL-BINDING  infor- 
mation object  class,  as  defined  in  Clause  23.3.1  of  Reference  [3].  This  specification  is  referenced 
whenever  a  DSA  performs  a  management  operation  on  the  operational  binding.  The  shadowing 
agreement  is  brought  into  effect  when  either  DSA  establishes  £in  instfince  of  the  operationjd  binding 
specified  for  it.  Once  in  effect,  the  operations  of  the  Directory  Information  Shadowing  Protocol 
(DISP)  are  used  to  carry  out  the  functions  associated  with  the  shadowing  agreement,  until  the 
operational  binding  specifying  the  shadowing  agreement  is  either  modified  or  terminated  by  either 
Directory  System  Agent.  Thus  the  DOP  eind  the  DISP  are  used  in  concert  in  order  to  define  a 
shadowing  agreement  and  carry  out  the  operations  necessary  to  mfdntain  it. 

2.10  Replication 

Replication  is  a  mechanism  used  within  the  Directory  whereby  information  stored  in  one  pMt 
of  the  Directory  may  also  be  stored  elsewhere  as  one  or  more  copies.  While  this  mechanism 
is  of  minimum  visibility  to  the  Directory  user,  it  has  the  advantages  that  it  increases  efficiency 
of  information  retrieval  «uid  decreases  response  time  to  operation  requests  by  placing  frequently 
accessed  information  "closer"  to  the  user. 

For  example,  in  a  situation  where  a  pairticul«ir  DSA  is  either  heavily  utilized  or  in  a  remote  location 
(perhaps  Europe  or  Asia)  or  both,  it  may  be  advsintageous  to  make  a  copy  of  the  DIT  subtree  we 
are  interested  in  on  the  remote  system  and  import  it  to  our  local  Directory  System  Agent.  This 
reduces  the  load  on  the  remote  DSA  and  improves  the  Directory's  performeince  from  our  point  of 
view,  because  our  access  to  the  data  is  much  faster. 

Replication  also  provides  an  extra  degree  of  reliability  find  robustness  to  the  Directory  in  that,  if 
one  of  the  systems  holding  a  copy  of  an  entry  becomes  inoperable,  the  information  may  still  be 
retrieved  from  einother  system. 

Replication  cairries  with  it  some  potential  pitfalls  as  well  as  advantages,  in  that  the  replicated 
information  may  not  be  up-to-date,  and  inconsistencies  may  exist  between  the  replicated  data  and 
the  master  copy.  How  long  these  inconsistencies  persist  will  depend  on  the  replication  agreement 
that  has  been  set  up  between  the  DSAs  concerned  -  the  copies  may  be  updated  immediately  upon 
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update  to  the  master,  or  periodiciilly,  perhaps  daily,  weekly,  etc.  However,  the  user  eJways  has  the 
option  to  request  information  directly  from  the  master  copy,  making  the  most  cxirrent  version  of 
the  information  available  if  necessary. 


2.10.1    Shadowing  and  Caching 

The  Directory  Standeird  describes  two  kinds  of  replication,  namely  Shadowing  axid  Caching.  Caching 
encompasses  any  non-standardized  method  for  replicating  data.  For  instance,  a  Directory  User 
Agent  (DUA)  may  simply  make  a  copy  of  every  entry  that  passes  through  it,  and  submit  that  copy 
in  response  to  a  query  about  the  entry,  rather  thjin  contact  the  Directory  to  request  the  informa- 
tion. It  is  easy  to  see  how  DSA  products  might  also  do  this  with  regard  to  entry  information  stored 
in  remote  Directory  System  Agents. 

Shadowing,  the  steindard  form  of  replication,  sets  up  replication  agreements  between  DSAs  speci- 
fying which  peirts  of  the  DIT  aie  to  be  replicated,  how  often  copies  are  to  be  updated,  whether  the 
copies,  in  part  or  in  whole,  may  be  copied  out  to  other  DSAs,  the  address  of  the  DSA  holding  the 
master  copy,  and  so  on.  These  agreements  are  set  up  via  Directory  Operational  Bindings,  which 
are  discussed  in  Section  2.9. 

2.10.1.1     Shadowed  Information 

The  replicated  Directory  information  is  always  in  the  form  of  a  contiguous  subtree  taken  from 
within  a  single  naming  context  on  the  master  DSA,  known  as  the  Shadow  Supplier.  The  unit 
of  replication'^^  in  shadowing  is  termed  Shadowed  Information,  which  encompasses  the  replicated 
information  (referred  to  as  the  replicated  area)  as  weU  as  information  about  its  origin,  extent,  etc. 
The  shadowed  information  has  three  components: 


Figure  2.12:  An  example  showing  shadowing  of  a  fragment  of  the  Directory  Information  Tree. 


For  the  formal  speciiacation  of  the  unit  of  replication,  see  Clause  9.2  of  Reference  [10]. 
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•  Prefix  information.  Information  regcurding  the  root  entry  of  the  replicated  subtree,  known 
as  the  replication  base  entry, 

•  Area  information.  Information  about  the  Directory  entries  contained  in  the  replicated 
£irea;  and 

•  Subordinate  information.  References  to  naming  contexts  subordinate  to  the  replicated 
£irea. 

In  Figure  2.12,  DSA  2  acts  as  a  Shadow  Supplier  to  DSA  3,  the  Shadow  Consimier.  The  DSA  3 
now  maintjiins  its  own  local  copy  of  the  Shadowed  Information. 

2.10.2    Shadow  Operational  Services 

The  updating  of  shadowed  information  is  accomplished  via  three  Directory  operations  which  consti- 
tute the  Directory  Information  Shadowing  Protocol,  or  DISP:  Coordinate  Shadow  Update,  Request 
Shadow  Update  and  Update  Shadow.  Through  these  services,  shadowed  information  can  be  updated 
at  the  instigation  of  either  the  shadow  supplier  or  shadow  consiuner. 

•  Coordinate  Shadow  Update.  This  service  is  used  by  the  shadow  supplier  to  indicate 
which  shadowed  information  it  intends  to  update,  £ind  how.  It  is  issued  in  response  to  a 
Request  Shadow  Update  operation  or  subsequently  to  £ui  Update  Shadow  operation; 

•  Request  Shadow  Update.  This  service  is  issued  by  the  shadow  consimier  (i.e.,  the  DSA 
holding  replicated  information)  in  order  to  request  an  update  of  the  shadowed  information; 
and 

•  Update  Shadow.  This  service  is  used  by  the  shadow  supplier  to  send  out  updated  shadow 
information  to  a  shadow  consumer.  It  is  invoked  only  after  one  of  the  previous  services. 

Each  exchange  CMries  information  about  the  shadowing  agreement  to  which  it  refers,  the  type  of 
update  to  be  performed  (complete,  incremental  or  no  cheinge),  and  so  on. 


32 


Chapter  3 

Functional  Evaluation  of  X.500 


3.1    Mandatory  Functions 

In  order  to  be  considered  a  candidate  for  proctirement,  an  X.500  product  must  satisfy  the  criteria 
set  out  in  this  section.  These  criteria  eire  derived  &om  the  International  Standfirds  Organization 
(ISO)  9594  set  of  stsuidards  (technicedly  aligned  with  the  CCITT  X.500  series  of  recommendations), 
Reference  [1],  the  Industry/ Government  Opens  Systems  Specification,  Reference  [11],  and  the  NIST 
Stable  Implemention  Agreements  for  Open  Systems  Interconnection  Protocols,  Reference  [12]. 

Since  the  Directory  is  composed  of  two  distinct  components,  the  Directory  System  Agents  and  the 
Directory  User  Agents  (DSAs  emd  DUAs),  requirements  for  each  type  of  component  are  set  out 
separately.  The  DSAs  are  further  subdivided  into  all  DSAs,  Shadow  Supplier  DSAs  and  Shadow 
Consimier  Directory  System  Agents. 

For  each  component,  the  requirements  fall  into  three  categories:  Statement  Requirements,  which 
describe  the  properties  and  capabilities  of  a  product  which  must  be  stated  by  vendors;  Static  Re- 
quirements, which  describe  invMifint,  mandatory  operational  requirements  placed  on  the  the  prod- 
uct; and  Dynamic  Requirements,  which  describe  operationfil  requirements  placed  on  the  product 
which  may  change  according  to  clrcTmist£inces. 

3.1.1    Directory  User  Agents 

3.1.1.1    Statement  Requirements  for  Directory  User  Agents 

The  manufacturer  of  a  DUA  product  must  state  the  following: 

Which  of  the  Directory  Access  Protocol  operations  conformance  is  claimed  for; 

The  authentication  capability  for  which  conformeince  is  claimed  (none,  simple  or  strong); 

Which  of  the  following  extensions  the  DUA  is  capable  of  initiating  and  for  which  conformance  is 
cledmed: 

1.  subentries.  If  this  service  control  is  set,  then  Search  and  List  operations  shfill  access  only 
subentries.  If  not  set,  these  operations  shall  access  only  normal  entries; 
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2.  copyShallDo.  This  service  control  indicates  that  a  query  need  not  be  chained  if  it  can  be 
partly  satisfied  from  a  local  copy  of  an  entry; 

3.  attributeSizeLimit.  This  service  control  indicates  the  majumum  permissible  size  of  ein 
attribute  for  it  to  be  returned  in  response  to  a  query.  If  an  attribute  exceeds  this  size,  it  is 
omitted  from  the  result,  and  a  flag  indicating  that  the  entry  result  is  incomplete  is  set; 

4.  extraAttributes.  This  component  of  the  EntrylnformationSelectiontype  (used  in  Read 
and  Search  requests  to  specify  which  information  should  be  returned)  is  used  to  specify 
additional  user  or  operational  attributes  to  be  included  in  the  result; 

5.  modifyRightsRequest.  This  component  of  the  Read  argument  is  used  to  request  the 
return  of  the  requestor's  modiflcation  rights  to  the  entry  and  its  attributes; 

6.  pagedResultsRequest.  This  component  of  the  List  argument  specifies  whether  results  of 
the  operation  are  to  be  returned  page  by  page; 

7.  matched  Values  Only.  This  component  of  the  Search  eirgument  specifies  that  attribute 
values  which  did  not  not  match  specificidly  with  values  in  the  sezirch  filter  shall  not  be 
returned; 

8.  extendedFilter.  This  component  of  the  Search  argument  specifies  an  eilternative  se£irch 
filter  for  use  by  1994-conformjint  systems; 

9.  target  System.  This  component  of  the  Add  Entry  argimient  specifies  the  DSA  which  shfill 
hold  the  new  entry; 

10.  useAliasOnUpdate.  This  describes  a  bit  in  the  criticalExtensions  element  of  Com- 
monArguments,  the  set  of  eirguments  common  to  all  operations. If  this  bit  it  set,  and 
the  dontDereferenceAlias  element  of  Common  Arguments  is  not  set,  £dias  entries  will 
be  dereferenced  during  the  commission  of  an  Add  Entry  operation;  find 

11.  newSuperior.  In  a  Modify DN  operation  eirgument,  this  component  specifies  the  name  of 
an  object  entry  in  the  DIT  which  is  to  become  the  new  superior  entry  of  the  entry  subject  to 
the  ModifyDN  operation. 

3.1.1.2    Static  Requirements  for  Directory  User  Agents 

The  Static  Reqidrements  for  DUAs  are  as  follows: 
Support  for  the  Bind  and  Unbind  operations  is  required; 

The  DUA  product  must  be  able  to  the  support  the  directory  Access  AC  application-context,  as 
defined  in  Clause  7  of  Reference  [6].  This  sets  out  the  protocols  and  abstract  syntjixes  to  be  used 
during  a  Directory  Access  session; 

The  DUA  product  must  be  able  to  hetndle  the  following  errors:  Abandoned,  AbandonFailed, 
AttributeError  and  NameError; 

The  product  must  be  capable  of  heindling  the  extensions  to  which  conformance  was  cledmed  in 
Section  3.1.1.1,  and  in  any  case  where  the  product  functions  as  an  IGOSS  Administrative  DUA 


2^ See  Section  2.6.9. 
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(i.e.,  a  DUA  capable  of  supporting  all  DAP  operations),  the  following  extensions  must  be  supported: 
extraAttributes,  subentries,  newSuperior  and  useAliasOnUpdate; 

The  product  must  support  the  character  set  requirements  set  out  in  Part  11,  Clause  7.1.1  of  Refer- 
ence [12],  i.e.,  T.61  String,  PrintableString,  NumericString  and  UNIVERSAL  STRING; 

The  product  must  support  None  and  ID-only/Simple  Uncorroborated  modes  of  authentication. 
In  the  former  method,  no  verification  of  the  user's  ID  is  carried  out  at  £iU,  while  ID-only  is  the 
simple  passing  of  a  user  ID,  which  is  checked  via  a  compare  operation  by  the  DSA  against  a  list  of 
legitimate  users;  and 

The  product  shall  have  the  capability  to  perform  the  normalization  of  protocol  elements  containing 
the  UTC  Time  element  according  to  the  rule  specified  in  Part  11,  Clause  A. 4.1  of  Reference  [12]. 
This  process  consists  of  filling  in  the  seconds  field  with  "00"  whenever  this  field  has  been  omitted, 
and  converting  the  string  to  the  "Z"  form. 

3.1.1.S    Dynamic  Requirements  for  Directory  User  Agents 

The  DUA  product  must  satisfy  the  following  Dynamic  Requirements  as  set  out  in  Reference  [6]: 

The  product  must  conform  to  the  mapping  onto  used  services  defined  in  Clause  8  of  Reference  [6]. 
This  mandates  the  mappings  between  the  X.500  services  and  those  of  the  supporting  Open  Systems 
Interconnection  (OSI)  services  (Association  Control  Service  Element  (ACSE),  Remote  Operation 
Service  Element  (ROSE),  Presentation,  Session,  and  so  on);  and 

The  product  must  conform  to  the  rules  of  extensibility  procedures  defined  in  Clause  7.5.1  of  Refer- 
ence [6].  These  rules  deal  with  the  interoperation  of  products  adhering  to  different  versions  of  the 
Directory  standetrd. 

3.1.2    Directory  System  Agents 

3.1.2.1    Statement  Requirements  for  Directory  System  Agents 
The  manufactxirer  must  state  the  following  with  regard  to  a  DSA  product: 

The  Application  Contexts  for  which  conformance  is  cleiimed:  directoryAccessAC,  directo- 
rySystemAC  and  directoryOperationalBindingManagement  AC.  If  knowledge  of  a  DSA  has 
been  disseminated  to  other  DSAs,  then  it  shall  claim  conformeince  to  the  directory  System  AC. 
Conformance  must  be  claimed  at  the  Application  Context  level  and  sh«iU  not  be  claimed  to  indi- 
vidufil  operations; 

The  operational  binding  types  for  which  conformance  is  cl£iimed:  shadowOperationalBindingID, 
specificHierarchicalBindingID,  and  non-specificHierarchicalBindingID; 

Whether  the  DSA  is  capable  of  acting  as  a  first  level  Directory  System  Agent; 

If  conformance  is  claimed  to  the  directorySystemAC,  whether  or  not  the  chsdned  mode  of  oper- 
ation is  supported; 

The  security  level(s)  for  which  conformeince  is  claimed  (none,  simple,  strong); 
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The  selected  attribute  types,  as  defined  in  Reference  [7],  £ind  any  other  attribute  types,  for  which 
conformfince  is  claimed  and  whether,  for  attributes  based  on  the  syntax  DirectoryString,  confor- 
mance is  claimed  for  the  UNIVERSAL  STRING  choice;^^ 

The  operational  attribute  tjrpes  defined  in  Reference  [3]  and  any  other  operationail  attribute  types 
for  which  conformjince  is  claimed; 

The  selected  object  classes,  as  defined  in  Reference  [8],  and  any  other  object  classes,  for  which 
conformance  is  claimed; 

The  extensions  listed  in  Table  1  of  Clause  7.3.1  of  Reference  [4]  that  the  DSA  is  capable  of  respond- 
ing to  for  which  conformance  is  claimed; 

Whether  conformjince  is  claimed  for  the  return  of  alias  names; 

Whether  conformance  is  claimed  for  indicating  that  returned  information  is  complete; 

Whether  conformance  is  claimed  for  modifying  the  object  class  attribute  to  add  and/or  remove 
values  identifying  auxilieiry  object  classes; 

Whether  conformaince  is  clsiimed  to  Basic  Access  Control; 

Whether  the  DSA  is  capable  of  administering  the  subschema  for  its  portion  of  the  Directory  Infor- 
mation Tree; 

The  selected  name  bindings,  and  any  other  name  bindings,  for  which  conformance  is  clsdmed;  and 

In  accordance  with  Reference  [12],  the  DSA  manufacturer  shall  state  to  which  of  the  following 
conformfince  classes  the  product  belongs: 

•  0:  Centralized  Directory  System  Agent.  Supports  only  the  directoryAccessAC;  or 

•  1:  Distributed  Directory  System  Agent.  The  DSA  shjJl  implement  all  operations  in  the 
Application  Service  Elements  forming  pMt  of  the  Application  Contexts  for  which  it  claims 
conformance.  The  DSA  shaH  support  the  directoryAccessAC  and  may  optionally  support 
the  directorySystemAC. 

3.1.2.2    Statement  Requirements  for  Shadow  Supplier  Directory  System  Agents 

In  addition  to  the  general  statements  described  above,  the  meinufacturer  of  a  DSA  product  claiming 
conformance  as  a  shadow  supplier  must  state  the  following: 

The  application  contexts  for  which  conformance  is  claimed  as  a  shadow  supplier:  shadowSuppli- 
erlnitiatedAC,  shadowConsumerlnitiatedAC,  reliableShadowSupplierlnitiatedAC,  and 
reliableShadowConsumerlnitiatedAC;  and 

To  which  degree  the  UnitOfReplication  is  supported.  Specifically,  which  (if  ciny)  of  the  following 
optional  features  aie  supported: 

•  Entry  filtering  on  Object  Class; 

^^It  is  a  static  reqixirement  that  all  selected  attribute  types  as  defined  in  Clause  5  of  Reference  [7]  should  be 
supported. 
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•  Selection/Exclusion  of  attributes  via  AttributeSelection; 

•  The  inclusion  of  subordinate  knowledge  in  the  replicated  area;  or 

•  The  inclusion  of  extended  knowledge  in  addition  to  subordinate  knowledge. 

3.1.2.3  Statement  Requirements  for  Shadow  Consumer  Directory  System  Agents 

In  addition  to  the  general  statements  described  above,  the  manufacturer  of  a  DSA  product  claiming 
conformance  as  a  shadow  consumer  must  state  the  following: 

The  application  contexts  for  which  conformance  is  claimed  as  a  shadow  consumer:  shadowSuppli- 
erlnitiatedAC,  shadowConsumerlnitiatedAC,  reliableShadowSupplierlnitiatedAC,  and 
reliableShadowConsumerlnitiatedAC; 

Whether  the  DSA  can  act  as  a  secondary  shadow  supplier;  £ind 

Whether  the  DSA  supports  shadowing  of  overlapping  units  of  replication. 

3.1.2.4  Static  Requirements  for  Directory  System  Agents 

In  addition  to  the  applicable  Statement  Requirements,  every  DSA  package  must  satisfy  the  following 
Static  Requirements: 

It  must  have  the  capability  to  support  the  application  contexts  for  which  conformance  is  claimed: 
aU  DSAs  shall  support  directoryAccessAC  or  directorySystemAC  or  both; 

It  must  have  the  capability  to  support  the  information  framework  defined  by  its  abstract  syntsix  in 
Reference  [3]; 

It  must  conform  to  minimal  knowledge  requirements  defined  in  Reference  [3],  i.e.,  each  non-first 
level  DSA  sheJl  maintain  a  single  superior  reference;  each  DSA  that  is  the  master  DSA  for  a  naming 
context  shall  maintain  subordinate  or  non-specific  subordinate  references  to  DSAs  holding  naming 
contexts  immediately  subordinate  to  that  naming  context; 

If  conformance  is  cledmed  as  a  first-level  DSA,  the  product  must  conform  to  the  requirements  for 
support  of  the  root  context; 

The  DSA  must  have  the  capability  to  support  the  attribute  types  for  which  conformance  is  claimed, 
as  defined  by  their  abstract  syntaxes,  eind  in  any  case  shall  support  the  selected  attribute  types 
defined  in  Reference  [7]  find  their  associated  attribute  syntaxes; 

It  must  have  the  capability  to  support  the  object  classes  for  which  conformaince  is  claimed,  and  in 
any  case  the  DSA  shall  support  all  selected  object  classes  defined  in  Reference  [8]; 

The  DSA  shaU  support  all  matching  rules  defined  in  Clause  7  of  Reference  [7]; 

The  product  must  conform  to  the  extensions  for  which  conformance  was  claimed; 

If  the  capability  to  administer  subschema,  as  defined  in  Reference  [3],  is  dfdmed,  the  DSA  shaR  be 
able  to  do  this  administration; 
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The  DSA  shall  support  collective  attributes,  and  must  have  the  capability  to  perform  the  related 
procedures,  as  outlined  in  Reference  [4]; 

The  DSA  shall  support  hierarchical  attributes,  and  must  have  the  capability  to  perform  related 
procedures,  as  outlined  in  Reference  [4]; 

The  DSA  must  have  the  capability  to  support  the  operational  attribute  types  for  which  conformance 
is  claimed; 

If  conformeince  is  claimed  to  Basic  Access  Control,  the  DSA  must  have  the  capability  to  hold  Access 
Control  Information  ( ACI)  items  conforming  to  the  definitions  of  Basic  Access  Control; 

The  DSA  shall  support  Simplified  Access  Control  (SAC).  A  class  2  subtree  specification,  as  de- 
scribed in  Part  11,  Clause  8.10  of  Reference  [12]  shall  be  supported; 

The  DSA  shall  support  operational  attributes  associated  with  the  supported  access  control  scheme(s), 
and  the  createTimestamp,  modifyTimestamp,  creatorsName  and  modifiersName  at- 
tributes; 

The  DSA  shall  support  the  UserPassword  attribute,  described  in  Reference  [9]; 

A  DSA  which  supports  any  kind  of  strong  authentication  sheJl  support  the  strongAuthentica- 
tionUser  £ind  certiflcationAuthority  attributes,  as  defined  in  Reference  [8]; 

A  DSA  supporting  any  form  of  strong  authentication  shall  support  the  following  attribute  types 
defined  in  Reference  [9]:  UserCertificate,  CACertificate,  CrossCertificatePair,Certificate- 
RevocationList  and  AuthorityRevocationList; 

The  DSA  shall  be  configurable  to  allow  new  attribute  types  to  be  defined  by  the  DSA  administrator. 
Extensibility  of  supported  attribute  types  shall  include  the  following  features: 

•  New  t3rpes  may  be  defined  in  terms  of  syntaxes  defined  in  Clause  6  of  Reference  [7];  and 

•  New  types  may  be  defined  in  terms  of  a  new  syntax  where: 

1.  The  S3mtax  is  one  of:  Integer,  Null,  Boolean,  Enumerated,  Bit  String,  Octet 
String,  Object  Identifier,  Distinguished  Name,  Case  Exact  String,  Case  Ig- 
nore String,  Numeric  String,  Printable  String,  UTC  Time  or  Telephone  Num- 
ber; 

2.  The  new  syntax  is  an  ASN.l  structured  type  (i.e.,  SET,  SEQUENCE,  SET  OF, 
SEQUENCE  OF  £ind  CHOICE),  possibly  including  tags,  where  each  component 
uses  one  of  the  syntax  forms  listed  in  the  previous  item;  and 

3.  The  matching  rule  associated  with  a  locally  defined  type  may  be  defined  using  any  of 
the  niles  described  in  Clause  7  of  Reference  [7]. 

The  DSA  shall  be  configurable  to  allow  new  object  classes  to  be  defined  by  the  DSA  administrator. 
Extensibility  of  supported  object  classes  shsdl  include  the  following  features: 

•  New  object  classes  may  be  defined  to  be  either  abstract,  structural  or  auxilieiry; 

•  A  new  object  class  may  be  a  subclass  of  £iny  class  described  in  Reference  [8]  or  it  may  be  a 
subclass  of  a  locally  defined  class;  and 
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•  A  new  object  class  may  be  defined  in  terms  of  any  combination  of  attribute  types  described 
in  Reference  [8]  and  locally  defined  attribute  types. 

The  DSA  shall  be  configtirable  to  allow  the  DSA  administrator  to  define  the  complete  set  of 
edlowed  name  bindings.  Each  of  the  name  bindings  described  in  Clause  7  of  Reference  [7]  shall  be 
implemented; 

The  DSA  shall  adhere  to  the  pragmatic  constraints  specified  in  Part  11,  Clause  7  of  Reference  [12]; 
and 

The  DSA  shall  adhere  to  requirements  in  Part  11,  Annex  A  of  Reference  [12]  regarding  the  Main- 
tenance of  Attribute  Syntaxes. 

Distributed  DS As  only.  The  following  requirements  apply  only  to  Distributed  DSAs,  as  defined 
in  Section  3.1.2.1. 

The  DSA  must  be  able  to  carry  out  name  resolution  and  search  continuation  for  an  alias  whose 
dereference  points  to  an  entry  held  outside  the  DSA,  as  described  in  Peirt  11,  Clause  9.1.5  of 
Reference  [12]; 

The  DSA  must  be  able  to  carry  out  simple  authentication  of  a  user  whose  entry  is  outside  the 
authenticating  DSA  as  described  in  Faxt  11  of  Reference  [12],  Clause  9.1.7; 

The  DSA  must  adhere  to  requirements  regarding  the  handling  of  the  Tracelnformation  attribute, 
as  specified  in  Part  11,  Clause  9.2.2  of  Reference  [12]; 

The  DSA  must  adhere  to  the  requirement  regarding  propagation  of  signed  arguments  specified  in 
Part  11  Clause  9.2.3  of  Reference  [12]; 

The  DSA  must  adhere  to  the  reqtiirement  regarding  referrals  and  chaining  specified  in  Part  11 
Clause  9.2.4  of  Reference  [12],  with  the  following  proviso: 

•  the  conditions  under  which  a  distributed  DSA  does  not  act  on  a  referral  include  the  following: 

-  The  returnToDUA  element  of  DSAReferral  indicates  the  referral  is  not  to  be  acted 
on;  or 

—  Administrative  limitations  or  service  policies  prevent  the  DSA  &om  acting  on  the  referral. 

The  DSA  must  adhere  to  imderlying  services  requirements  specified  in  Peirt  11,  Clause  10  of  Ref- 
erence [12]; 

The  DSA  shall  be  capable  of  supporting  the  structure  £ind  naming  rules  defined  in  Reference  [8], 
Annex  B; 

The  DSA  shall  be  able  to  support  all  superclasses  of  supported  object  classes; 

The  DSA  shall  be  able  to  support  the  storage  and  use  of  attribute  type  information,  as  defined  in 
the  Reference  [7],  including  their  use  in  naming  and  access  to  entries; 

The  DSA  shall  support  the  encoding,  decoding  and  matching  of  edl  the  attributes  in  the  Naming 
Prefixes  of  every  naming  context  they  hold  (see  Reference  [5],  Clause  9); 
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The  attributes  and  attribute  sets  in  Reference  [7],  associated  with  the  object  classes  listed  below 
are  required.  The  storage  and  use  of  the  object  classes  below  is  also  required: 

Top,  DSA,  Alias,  Country,  Locality,  Application  Process,  Organization, 
Organizational  Unit,  Application£ntity,Device,  Group  of  Names, 
OrganizationalPerson,  OrganizationalRole,  ResidentialPerson 

An  object  class  may  not  be  defined  as  a  subclass  of  itself; 

The  DSA  must  support  all  character  sets  and/or  other  nameforms  defined  in  Reference  [7],  including 
T.61,  PrintableString  etnd  NumericString; 

It  is  a  minimnTn  requirement  that  invoke  Application  Protocol  Data  Units  (APDUs)  and  return 
result  APDUs  shall  be  accepted  unless  their  size  exceeds  2**18  -  1  (262,143)  octets; 

At  minimum,  8  nested  Filter  parameters  will  be  supported,  with  a  toted  limit  of  32  Filterltems; 

All  distributed  DSAs  shall  be  capable  of  acting  as  a  holder  and  a  propagator  of  Directory  informa- 
tion; 

The  DSA  shall  support  the  Versions  component  of  the  Bind  argtunent; 

The  DSA  shall  support  the  Reference  [12]  Directory  Common  Application  Directory  Profile; 

The  DSA  shiJl  be  able  to  hold  eind  use  the  following  reference  types: 

•  superior:   Non-first  level  DSAs  shall  have  precisely  one.  First  level  DSAs  have  none; 

•  subordinate:  Meindatory; 

•  cross:   Memdatory;  and 

•  non-specific  subordinate:  Optional. 

A  first  level  DSA  shall  be  able  to  hold  and  use  the  root  context'^^  and  shsM  hold  as  master  at  least 
one  naming  context  immediately  subordinate  to  the  root  of  the  Directory  Information  Tree; 

If  the  DSA  supports  the  directorySystemAC  it  must  be  able  to  accept  a  chained  request  and 
generate  a  referred; 

In  order  to  perform  simple  authentication  of  a  user  whose  entry  potentizilly  resides  on  another  DSA, 
a  DSA  must  be  able  to  invoke  DSA  Compare  and  Read  operations,  and  must  thus  support  the 
directorySystemAC;^^  and 

If  the  propagation  of  a  Search  operation  involves  request  decomposition,  the  tracelnformation 
argument  of  the  origineil  Seeirch  request  sheiU  not  be  reset,  rather  the  full  tracelnformation  for  the 
overaiU  Search  to  the  point  where  one  or  more  new  Search  requests  are  generated  shsJl  be  included 
in  the  new  Search  requests; 

^'I.e.  a  first-level  DSA  shall  act  as  if  it  holds  the  (hypothetical)  root  of  the  Directory  Information  Tree. 
^*In  order  to  perform  simple  authentication  of  a  user  whose  entry  potentially  resides  on  another  Directory  System 
Agent. 
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Centralized  DS  As  only.  The  following  requirements  apply  only  to  CentraJized  DS  As,  as  defined 
in  Section  3.1.2.1. 

The  DSA  must  not  implement  shadowing. 

3.1.2.5    Static  Requirements  for  Shadow  Supplier  and  Consumer  Directory  System 
Agents 

In  addition  to  the  generzJ  statement  requirements,  the  statement  reqiiirements  for  Shadow  Supplier 
DSAs,  the  statement  requirements  for  Shadow  Consumer  DSAs  and  the  general  static  requirements, 
Shadow  Supplier  £ind  Consumer  DSA  packages  must  satisfy  the  following  static  reqtiirements: 

A  DSA  shedl,  at  a  minimum,  support  either  the  shadowSupplierlnitiatedAC  or  the  shadow- 
ConsumerlnitiatedAC.  If  the  DSA  supports  the  shadowSupplierlnitiatedAC,  it  may  option- 
ally support  the  reliableShadowSupplierlnitiatedAC.  If  the  DSA  supports  the  shadowCon- 
sumerlnitiatedAC,  it  may  optioneilly  support  the  reliableShadowConsumerlnitiatedAC; 

Each  shadow  supplier  DSA  shaH  maintain  a  consxrmer  reference  for  each  shadow  consumer  DSA 
that  it  supplies  with  a  replicated  area; 

Each  shadow  consvmier  DSA  shall  maintain  a  supplier  reference  for  each  shadow  supplier  DSA  that 
supplies  it  with  a  replicated  eirea; 

The  DSA  must  support  the  modifyXimeStamp  and  createTimeStamp  operational  attributes; 
The  DSA  must  provide  support  for  the  copyShallDo  service  control; 

The  DSA  must  implement  the  Directory  Information  Shadowing  Protocol  (DISP)  as  de- 
scribed in  Reference  [12]  Pfirt  11,  Clause  8.11.^^  A  class  2  unit  of  replication,  as  described  in 
Reference  [12]  Part  11,  Clause  8.11.3,  shaill  be  supported; 

AU  DSAs  implementing  the  DISP  shall  be  capable  of  acting  as  both  shadow  supplier  and  consimier 
as  defined  in  Reference  [10],  Clause  3  and  shaH  meet  conformance  requirements  stated  in  Reference 
[6],  Clauses  9.3  and  9.4; 

The  DSA  shall  also  support  minimmn  shadowing  requirements: 

•  Support  for  both  directoryShadowConsumerAC  and  directoryShadowSupplierAC; 

•  Support  for  an  updateMode  whose  mode  choice  includes  a  specification  of  schedulingPa- 
rameters;  and 

•  Support  for  schedulingParameters  specifications  which  specify  a  periodic  strategy. 
The  product  supplier  shall  state  which  Unit  of  Replication  conform£ince  class  is  supported: 

•  0:  Basic  Unit OfReplicat ion.  The  DSA  shall  be  capable  of  shadowing  a  imit  of  replication 
with  the  following  characteristics: 

1.  The  eirea  includes  a  class  0  subtree  as  defined  in  Reference  [12];  and 
^'See  also  Section  2.10. 
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2.  The  area  includes  a  specified  knowledgeType  (e.g.,  master,  copy  or  both). 

•  1:  Intermediate  Unit OfReplicat ion.  The  Directory  System  Agent  shaR  fully  support  Basic 
UnitOfReplication  and  shall  also  be  capable  of  shadowing  a  unit  of  replication  with  the 
following  characteristics: 

1.  The  area  includes  a  class  1  subtree  as  defined  in  Part  11,  Clause  8.10  of  Reference  [12]; 
and 

2.  The  knowledge  includes  an  extendedKnowledge  element  with  value  TRUE. 

•  2:  Mfiximal  UnitOfReplication.  The  DSA  shall  fully  support  class  1  and  shall  be  capable 
of  shadowing  a  xmit  of  replication  whose  specification  uses  AttributeSelection  (including 
selection  on  class).  The  DSA  shall  be  capable  of  supporting  overlapping  replicated  areas  as 
described  in  Reference  [10],  Clause  9.2.5. 

3.1.2.6    Dynamic  Requirements  for  all  Directory  System  Agents 

All  DSAs  must  satisfy  the  following  dynamic  requirements: 

Conform  to  mapping  onto  used  services  defined  in  Clause  8  of  Reference  [6]; 

Conform  to  procedures  for  distributed  operation  of  the  Directory  related  to  referrals,  as  defined  in 
Reference  [5]; 

If  conformance  is  claimed  to  the  directory  Access  AC  application  context,  conform  to  the  proce- 
dures of  Reference  [5]  as  they  relate  to  the  referral  mode  of  the  Directory  Access  Protocol; 

If  conformance  is  claimed  to  the  directory  System  AC  application  context,  conform  to  the  referral 
mode  of  interaction,  as  defined  in  Reference  [5]; 

K  conform£ince  is  claimed  to  the  chained  mode  of  interaction,  conform  to  the  chained  mode  of 
interaction,  as  defined  in  Reference  [5]; 

Conform  to  the  rules  of  extensibility  defined  in  Clause  7.5.2  of  Reference  [6]; 

If  conformance  is  claimed  to  Basic  Access  Control,  have  the  capability  of  protecting  information 
within  the  DSA  in  accordance  with  the  procedures  for  Basic  Access  Control; 

If  conformance  is  claimed  to  the  shadowOperationalBindingID,  conform  to  the  procedtires  of 
Reference  [10]  and  Reference  [3]  as  they  relate  to  the  Directory  Access  Protocol; 

J£  conform£ince  is  claimed  to  the  specificHierarchicalBindingID,  conform  to  the  procedures  of 
Reference  [5]  and  Reference  [3]  as  they  relate  to  specific  hierarchical  operational  bindings; 

If  conformzince  is  claimed  to  the  non-specificHierarchicalBindingID,  conform  to  the  procedures 
of  Reference  [3]  and  Reference  [5]  as  they  relate  to  non-specific  hierarchical  operational  bindings; 
and 

The  DSA  shall  adhere  to  requirements  to  support  Session  Version  2  as  described  in  Part  11,  Clause 
10.2  of  Reference  [12]. 
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3.1.2.7    Dynamic  Requirements  for  Shadow  Supplier  and  Shadow  Consumer  Direc- 
tory System  Agents 

All  Shadow  Supplier  and  Shadow  Consumer  DSAs  must  satisfy  the  following  dynamic  requirement: 

Conform  to  the  procedures  of  Reference  [10]  as  they  relate  to  the  Directory  Information  Shad- 
owing Protocol. 

3.2    Non-Standard  Functions 

Section  3.1  describes  the  features  £ind  capabilities  which  an  X.500  Directory  product  must  have  in 
order  to  satisfy  current  U.S.  federal  government  procurement  guidelines.  However,  these  features 
£ind  capabilities,  though  essential,  provide  only  the  bare  skeleton  of  functiontility  required  for  an 
efficient  and  usable  Directory  system. 

This  section  sets  out  to  explore  some  non-mandatory,  sometimes  even  non-standeird  features 
which  can  enhance  the  performance  and  usability  of  the  Directory  as  an  information  storage  and 
retrieviil  tool.  As  in  Section  3.1,  Directory  User  Agents  and  Directory  System  Agents  will  be  treated 
separately,  except  in  the  criticfil  area  of  interoperability,  to  which  a  specific  section  is  dedicated. 

3.2.1  Interoperability 

Interoperability  between  two  Directory  components  means  that  they  should  be  able  to  exchange 
Directory  operation  requests,  results  £ind  errors  without  error  and  with  a  mutual  interpretation  of 
the  various  p£urameters  and  their  values  which  appear  in  the  protocol  exchanges.  Inter  op  erabihty 
between  two  instances  of  the  same  product  is  usueilly  taken  for  granted,  so  the  term  usujilly  ap- 
plies to  the  inter-working  of  two  or  more  implementations  from  different  vendors,  or  two  or  more 
different  implementations  from  the  same  vendor.  While  it  may  seem  self-evident  at  first  that  two 
implementations  of  the  same  standard  should  inevitably  work  together,  experience  has  shown  that 
this  is  rarely  the  case,  at  least  not  initieJly.  Despite  the  C£ireful  leinguage  of  the  steindfirds  themselves 
and  the  work  put  into  the  production  of  various  sets  of  Implementors'  Agreements'^  and  standards 
profiles,  ambigtuties  often  exist,  and  different  interpretations  on  the  part  of  software  production 
staff  of  different  vendors  invariably  occur. 

Various  guides  to  X.500  product  interoperability  exist:  the  OSINET  Stable  Interoperability  Tests 
docimient.  Reference  [14],  gives  the  results  of  interoperability  testing  performed  between  different 
X.500  products  in  a  controlled  environment.  At  the  time  of  writing,  the  Joint  Interoperability 
Test  Command  (JITC)  of  the  Defense  Information  Systems  Agency  (DISA)  of  the  Department 
of  Defense  (DoD)  is  also  performing  X.500  conformance  and  interoperability  tests  £ind  recording 
the  results  in  a  publicly  accessible  register.  If  the  product(s)  under  consideration  is  (are)  not 
included  in  these  sources,  then  the  manufacturer  shotdd  be  considted  as  to  whether  the  product 
will  interoperate  with  all  the  other  systems  xmder  consideration,  and  should  be  held  accotmtable 
to  any  clfdms  made. 

Interoperability  between  different  components  of  an  organization's  Directory  system  is  always  highly 

^'Non-standard  in  the  sense  that  the  features  lie  outside  the  scope  of  the  Standard. 
^^See,  for  example,  Reference  [12]. 
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Figure  3.1:  Interoperability  in  the  X.500  Directory. 
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desirable,  but  there  are  two  situations  in  which  it  becomes  critical:  when  policy  or  circumstEuices 
dictate  that  the  Directory  will  be  made  up  of  heterogeneous  components  (i.e.,  components  from 
different  manufacturers;  different  products  from  the  same  manufacturer;  different  releases  of  the 
same  product  line  from  the  same  manufacturer;  and  so  on);  and  when  policy  or  circumstances 
dictate  that  the  organizationzil  Directory  must  communicate  with  other  X.500  instfiUations  outside 
the  organization,  which  in  aU  probability  will  use  software  and/or  hardware  which  differs  in  some 
way  from  that  in  use  locjilly.^® 

All  DUAs  should  be  able  to  interoperate  with  any  DSA  component  in  the  orgfinization's  locsJ 
Directory.  All  DSAs  should  be  capable  of  interoperating  with  all  DUAs  and  all  DSAs  in  the 
organization.  Figure  3.1  gives  a  schematic  rendition  of  this  idea. 

3.2.2    Directory  User  Agents 

Many  of  the  features  considered  in  this  section  apply  to  the  humein  user  interface  to  the  DUA,  as 
opposed  to  the  protocol  engine  component,  but  the  two  components  £ire  treated  together  here  since 
the  Directory  Standfird  regards  the  user  interface  as  £in  integral  part  of  the  DUA  (see  Reference  [3], 
Clause  6.2,  Note  3).  Beeiring  in  mind  the  potentially  huge  range  of  possibilities  for  the  presentation 
and  mauiptdation  of  Directory  information,  it  is  only  possible  to  discuss  the  most  generail  principles 
here,  find,  even  so,  possibilities  may  be  missed. 

Six  general  principles,  which  can  be  roughly  grouped  into  three  pairs,  will  be  used  as  the  framework 
for  exploring  the  reedization  of  the  DUA's  potential.  Configurability  find  Ease  of  Integration  enable 
the  product  to  be  tailored  to  best  suit  the  user's  requirements  while  creating  minimfJ  disturbance  to 
the  established  user  environment.  Accessibility  of  the  information  held  in  the  Directory  find  Clarity 
in  the  presentation  of  this  information  are  vital  if  the  service  is  to  be  of  genuine  use,  providing 
ease  of  access  to  needed  information.  FinfJly,  Ease  of  Operation  and  Informativeness  deal  with  the 
need  for  the  product  to  enhance  rather  than  impede  the  user's  access  to  information,  providing  an 
easily  imderstood  interface  with  detailed  and  informative  help  pages  at  each  step. 

3.2.2.1    Ease  of  Configuration 

One  quality  which  is  highly  desirable  for  all  features  of  the  DUA  is  that  they  be  easy  to  configure. 
In  addition,  reconfigtiration  of  any  featxire  should  cause  a  minimimi  of  disturbance  to  the  system. 
For  exfimple,  no  rebooting  or  restfirting  of  the  softwfire  should  be  necessary  in  order  to  reconfigure 
a  feature:  the  operation  of  the  DUA  should  be  essentially  imdisturbed.  Also,  the  reconfiguration 
should  go  into  effect  immediately  fifter  it  is  complete,  and  be  applied  to  subsequent  operations. 
However,  resTilts  of  finy  Directory  operations  initiated  prior  to  the  reconfigiiration  may  need  to  be 
treated  in  accordance  with  the  configuration  in  place  when  the  corresponding  operation  request 
was  issued. 

Additionally,  it  should  be  possible  to  configure  each  feature  from  outside  the  DUA  itself  (i.e.,  when 
the  DUA  is  not  r\mning,  or  as  the  enactment  of  a  system- wide  configuration  policy)  by  editing  some 
configuration  file,  using  either  a  reguleir  text  editor  or  a  tool  specialized  for  the  task  (preferably 
both),  which  is  judged  to  be  the  best  suited  to  the  local  user  community. 

^'As  well  as  differences  between  the  X.500  products  themselves,  there  may  be  differences  in  the  underljring  com- 
munications software.  Such  differences  are  not  addressed  here. 
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Examples  of  features  that  it  should  be  possible  to  configure  in  accordance  with  the  principles  laid 
out  above  include: 


•  Common  Arguments.  The  Common  Arguments^^  associated  with  each  Directory  Opera- 
tion are  often  relatively  constant  for  the  duration  of  a  session,  and  as  such  may  be  inserted 
into  each  operation  automatically  by  the  DUA,  without  the  need  for  the  user  to  enter  them 
individually.  They  should  be  easy  to  configure  and  easily  modified.  For  exaimple,  the  system 
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Figure  3.2:  An  example  of  a  menu-based  editor  for  Common  Arguments. 

might  provide  a  default  Common  Argxma.ents  configuration  file  for  each  user,  which  is  easily 
modified  at  any  time,  either  during  a  session  by  using  a  specialized  tool  such  as  an  editable 
pop-up  menu,  or  outside  sessions  by  simply  editing  the  file  with  a  normal  text  editor  or  special 
tool  provided  for  the  purpose.  Figure  3.2  shows  a  simple  example  of  a  tool  for  editing  the 
Common  Argiunents  pMameter. 

•  Local  Caching  Capability.  It  is  possible  for  a  DUA  to  cache  Directory  information  by 
simply  storing  any  information  it  receives  from  a  Directory  System  Agent.  Such  caching  is 
outside  the  scope  of  the  Standjird,  and  it  is  not  possible  to  set  up  an  agreement  between  DUA 
and  DSA  to  ensure  updates  to  the  cached  information,  etc.,  but  local  caching  can  nevertheless 
prove  to  be  a  useful  tool  and  can  help  increase  retrieval  speed  for  the  user  while  decreasing 
network  treiffic  cind  DSA  workload.  Local  caching  algorithms  c£ui  vaiy  from  the  most  basic 
(e.g.,  store  aU  information  received  for  a  designated  time  period,  indexing  by  distinguished 
name)  to  the  more  elaborate.  For  exeimple,  if  a  certain  entry  is  accessed  more  thein  a  threshold 
niunber  of  times  dtiring  a  session,  the  DUA  may  be  configured  to  send  out  ajx  independent 
Read  operation  to  obtain  all  possible  information  from  the  entry  in  question,  sind  use  the 
cached  information  to  satisfy  subsequent  queries  about  the  entry.  In  this  latter  case,  the 
DUA  is  acting  "in  the  background,"  independently  of  the  user,  to  obteun  information  that  it 
is  assumed  the  user  is  likely  to  need. 

See  Section  2.6  for  more  on  Common  Arguments. 
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•  Specification  of  Nonstandard  Schema  Elements.  It  is  regarded  as  essentieil  that  the 
user  or  administrator  of  a  DUA  be  able  to  define  nonstandard  schema  elements  designed  to 
accommodate  locfJ  requirements.  For  the  DUA,  these  elements  are  attribute  types,  object 
classes  and  DIT  content  rules.  Ideally,  these  can  be  specified  either  with  a  regular  text  editor, 
using  specified  formats,  or  by  using  specialized  tools  provided  with  the  DUA  software.  The 
definition  mecheinisms  shoidd  incorporate  the  notions  of  attribute  hierarchies,  object  class 
(midtiple)  inheritfince,  and  so  on.  Any  tools  provided  will  likely  be  windows-based  for  clarity 
of  information  presentation. 

•  Default  DSA  Specification.  It  should  be  possible  for  a  user  to  specify  a  "default"  DSA 
with  which  to  bind  when  initiating  a  Directory  session,  possibly  along  with  a  list  of  backup 
DSAs  to  contact,  in  order  of  preference,  if  the  preferred  DSA  is  imavailable  for  some  reason. 
This  avoids  the  need  for  the  user  to  specify  a  particular  DSA  on  each  bind  attempt,  and  thus 
saves  time  and  effort,  while  furthering  the  notion  that  the  user  is  connecting  to  the  Directory 
as  a  whole,  as  opposed  to  a  single  server. 

Alternatively,  a  list  of  possible  DSAs  to  contact,  labelled  with  user-friendly  names,  coidd 
be  displayed,  enabling  the  user  to  simply  click  on  the  desired  name  in  order  to  bind  to  the 
Directory. 

•  Default  "Home  Position".  Such  a  feature  would  enable  the  user  to  configure  £in  entry  in 
the  Directory  which  would  be  the  default  position  at  which  all  operations  would  be  targeted. 
For  instance,  this  may  be  the  user's  own  entry,  or  the  naming  context  prefix  for  a  naming 
context  in  which  a  user  or  application  carries  out  most  processing.  Optionally,  this  entry 
could  be  read  and  displayed  when  the  user  binds  to  the  Directory. 

•  "Hot  list"  of  Commonly  Accessed  Entries.  Similar  to  the  default  home  position,  this 
feature  would  enable  the  user  to  configure  a  list  of  commonly  accessed  entries  or  entry  dis- 
tinguished name  prefixes,  which  coidd  be  brought  up  on  a  pop-up  menu  and  easily  selected 
with  a  mouse,  saving  the  typing  of  often  long  Distinguished  Ncimes. 

•  Full  or  Abbreviated  Attribute  Names.  The  DUA  should  be  easily  configurable  for  the 
input  and  display  of  full  length  (e.g.,  "Organizational  Unit")  or  abbreviated  attribute  names 
(e.g.,  «0U"). 

•  Confirmation  Request.  Before  the  submission  of  each  operation  request  to  the  Directory, 
the  user  may  be  prompted  by  the  DUA  interface  as  to  whether  the  request  is  ready  for 
submission.  The  default  condition  could  be  set  as  a  toggle. 

This  is  only  a  selection  of  features  which  can  and  should  be  easily  configurable  by  the  user.  In 
the  sections  that  follow,  other  features  exeunined  in  different  contexts  wiU  also  be  seen  to  be  clear 
c£indidates  for  user  configuration. 

3.2.2.2    Ease  of  Integration 

An  X.500  DUA  product  shoidd  be  easily  integrable  into  the  user's  existing  computing  environment, 
introducing  the  minimum  of  additional  complexity  and  presenting  an  interface  which  is  easily 
understood  and  based  on  cleeir,  open  principles.  Above  all,  any  DUA  package  should  be  known  in 
advance  to  be  capable  of  interoperating  with  £iny  DSA  package  in  the  organization.  Some  ways  in 
which  a  product  may  achieve  these  gosds  include: 
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•  User  Interface.  The  user  interface  of  the  DUA  should  be  able  to  nin  under  a  variety 
of  widely  used,  de  facto  or  de  jure  standard  operating  system  packages,  such  as  the  veirious 
windowing  environments  that  are  currently  available.  For  clarity  of  presentation,  it  is  desirable 
that  the  DUA  use  some  kind  of  windowing  system,  the  point  here  being  that  it  should  have 
the  capability  to  fit  easily  into  whatever  system  is  currently  in  use  at  the  user  site. 

•  X.400  Integration.  The  principal  use  of  the  Directory,  at  least  initially,  is  envisioned  to  be 
as  a  name  to  address  lookup  facility  for  X.400-based  electronic  mail  systems.  With  this  in 
mind,  it  is  seen  as  highly  desirable  that  the  DUA  provide  a  programmatic  interface  or  API  to 
such  systems.  The  Directory  standard  contains  various  definitions  which  allow  for  the  storage 
of  X.400  information,  eind  X.400-based  systems  should  be  equipped  to  query  the  Directory 
for  this  Information.  See  also  the  next  item. 

•  Standard  Application  Programming  Interface.  The  progrtimmatic  interface  to  the 
DUA  should  be  based  on  the  Portable  Operating  System  Interface  (PO SIX) /Institute  of 
Electriceil  and  Electronic  Engineers  (IEEE)  API  for  Directory  operations,  Reference  [13],  or 
some  other  widely  accepted  standard.  This  enables  applications  developers  at  the  user  site  to 
develop  applications  aroimd  a  standardized  set  of  function  calls  in  order  to  Directory- enable 
their  software.  It  also  should  minimize  the  Jimount  of  developer  effort  expended  if  Directory 
products  Me  switched,  thereby  empowering  the  user  community  with  the  ability  to  select 
X.500  products  on  the  basis  of  other,  more  significant  features. 

•  Variety  of  Platforms.  The  product  should  be  available  to  run  on  a  variety  of  hardware 
and  softweire  platforms.  In  pjirticular,  from  the  user's  point  of  view,  it  should  be  available  to 
nm  on  all  platforms  in  use  at  the  user's  site  at  the  time  of  purchase. 

•  Communications  Architecture.  The  product  should  be  able  to  accommodate  the  var- 
ious types  of  communications  zirchitecture  in  place  at  the  user  site,  including  pure  Open 
Systems  Interconnection  (OSI),  mixed  OSI- Transmission  Control  Protocol/Internet  Proto- 
col (TCP/IP)  (i.e.,  Request  For  Comments  (RFC)  1006,  Reference  [15]),  or  whatever  other 
communications  architecture  may  be  present. 

3.2.2.3    Accessibility  of  Data 

The  purpose  of  the  DUA  is  to  obtain  information  from  the  Directory  eind  present  it  to  the  user.  The 
DUA  product  should  do  as  much  as  possible  to  enhance  the  accessibility  of  Directory  information; 
for  ex£imple,  by  msdcing  it  easier  for  the  user  to  compose  the  Directory  operations  necessary  for  the 
effective  retrieval  of  the  desired  information.  Some  exeimples  of  how  this  might  be  done  are  given 
below: 

•  Handling  of  Referrals. ^°  When  a  referred  is  received  by  the  DUA,  several  courses  of  action 
are  open  to  it.  The  referred  information,  or  just  the  fact  that  a  referral  has  been  received 
in  connection  with  a  particular  operation,  might  simply  be  passed  on  to  the  user.  This 
information  could  be  accompanied  by  £in  option  for  the  user  to  select  whether  to  proceed  with 
or  terminate  the  operation.  Alternatively,  the  DUA  could  pursue  the  referral  automatically, 
possibly  flagging  the  user  that  it  has  done  so  -  both  these  options  shoidd  be  configurable  by 

'°See  Section  2.6  for  an  explanation  of  Referrals. 
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the  user.  In  the  simplest  case,  the  referral  may  just  be  discarded  and  the  operation  logged  as 
unsuccessful. 

t  Automatic  Bind.  The  DUA  might  automaticedly  bind  to  a  defaidt  DSA  on  start-up,  en- 
abling the  user  to  begin  work  immediately.^^  This  feature  should  be  configTirable. 

•  FoUowup  List  Operation.  The  DUA  might  issue  a  List  operation  automatically  £ifter  every 
Read  operation  to  show  the  subordinates  of  the  entry  on  which  the  operation  was  performed. 
This  information  in  turn  might  be  used  to  create  a  d3mamic  graphic  representation  of  the 
DIT  in  the  area  in  which  work  is  being  performed.  This  feature  should  be  configurable. 

•  Tree  Build.  The  user  may  wish  to  see  a  graphical  representation  of  the  DIT  at  the  point 
at  which  he/she  is  working.  This  might  be  achieved  by  the  provision  of  a  utility  in  the 
DUA  which,  through  the  automatic  issuance  of  a  succession  of  List  requests,  cam  obtain  the 
information  necessary  to  build  a  graphical  representation  of  the  requested  DIT  fragment.  The 
user  might  specify  the  number  of  levels  of  the  DIT  to  be  diagrammed,  relative  to  a  given  target 
entry,  both  above  tind  below  that  entry.  To  take  this  level  of  accessibility  to  the  next  logicsd 
step,  Directory  operations  should  be  tfirgetable  at  entries  in  the  displayed  DIT  fragment  by 
clicking  on  the  displayed  entry  using  the  mouse  or  other  pointing  device.  A  defaiilt  value 
shoidd  be  configtirable  for  the  number  of  levels  to  be  displayed,  and  a  system-wide  default 
may  obteiin.  Access  controls  may  prevent  a  full  picture  from  being  displayed. 

3.2.2.4    Clarity  of  Presentation 

In  order  to  optimize  the  useftdness  of  Directory  information  to  the  Directory  user,  the  X.500 
product  user  interface  should  display  all  information  with  the  greatest  possible  cl£irity.  For  all 
practical  purposes  at  the  present  time,  a  windows  based  approach  is  the  most  desirable  means  for 
the  display  of  information.  This  enables  different  information  objects  or  groupings  of  objects  to  be 
displayed  as  separate  entities,  drag  and  drop/cut  and  paste  features,  point  £Uid  click  functionality, 
eind  so  on,  minimizing  the  amoimt  of  time  spent  by  the  user  on  such  tedious  tasks  as  typing 
Distingtushed  Names  and  repeating  operations  with  slightly  different  parjimeters.  Some  features 
which  might  aid  in  the  cleirity  of  presentation  of  information  follow: 

•  Pop-up  Displays.  Each  information  item  (for  example,  the  contents  of  a  Directory  entry, 
the  result  of  a  Read  operation)  is  displayed  as  a  list  of  items  in  a  pop-up  window.  Each  item 
consists  of  the  attribute  type  and  vadue(s).  When  there  is  more  thein  one  value  associated 
with  £in  attribute,  or  the  attribute  has  a  complex  syntax,  then  the  entire  yalue  or  value  set 
is  displayed  in  a  new  window  by  clicking  on  the  initisd  item.  This  process  is  recursive  for 
complex  elements. 

•  Highlighting  of  Distinguished  Values.  Distinguished  attribute  values  might  be  high- 
lighted or  otherwise  indicated  so  that  the  entry's  Relative  Distingxushed  Name  can  easily  be 
read. 

'^Usually  such  an  automatic  bind  will  grant  the  user  only  public  access  rights  in  the  Directory.  The  user  will 
need  to  be  re-authenticated  if  greater  access  rights  are  required.  The  point  here  is  that  the  DUA  is  "ready  to  go" 
immediately  on  start-up. 
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3.2.2.6    Ease  of  Operation 


Ideally,  when  using  the  Directory,  information  recovery  is  optimized  against  the  effort  expended 
by  the  user.  In  other  words,  the  user  should  be  able  to  recover  the  maximum  information  for 
the  minimum  time  and  effort.  To  this  end,  the  User  Interface  should  include  tools  to  assist  in 
the  composition  of  Directory  operation  argtunents,  so  that  these  argimients  can  be  assembled  as 
quickly  and  easily,  and  with  as  few  errors  as  possible.  One  example  of  such  a  tool  is  the  Common 
Arguments  editor  mentioned  in  Section  3.2.2.1.  Additional  examples  of  important  areas  to  be 
addressed  by  such  tools  are: 

e  Search  Filter  Editor.  The  avedlability  of  a  tool  to  enable  the  user  to  quickly  and  accurately 
build  a  search  filter  is  highly  desirable,  since  it  is  through  the  Search  operation  that  most 
Directory  interrogation  is  likely  to  take  place.  Such  a  tool  might  permit  the  user  to  specify 
the  filter  in  a  way  similsir  to  a  Structured  Query  Language  (SQL)  SELECT  commemd,  or 
it  might  allow  the  user  to  biiild  the  filter  in  a  display  window,  using  cut  find  pastes  from 

Search  Filter  Editor 


Attribute  Menu 


Country  Name 

Organizatioa 

Locality 

Telephone 

X.400  Address 

Common  Name 

Surname 


X 


Operator  Menu 

EQUAl^ 

AND 

OR 

NOT 

>= 

<= 

SUJBSTRING . . . 

ANY 


INITIAL 


TERMINAL 


[Filter  Construction  Panel  ) 
(surname  EQUALS  "Lester"  AND  Organization  SUBSTRING  "Agriculture"  ) 


Figure  3.3:  An  example  of  a  windows-based  Search  Filter  Editor. 

other  windows.  These  windows  would  include  a  pop-up  menu  of  aveiilable  attribute  tjrpes, 
where  selecting  a  type  inserts  the  type  into  the  filter  imder  construction;  a  similfir,  smaller, 
pop-up  menu  containing  the  logiceJ  connectors  for  the  search  filter;  and  a  display  window 
which  shows  the  filter  at  its  present  stage  of  construction  (see  fig.  3.3).  In  this  way,  the  user 
needs  only  to  type  the  attribute  vjilues  s /he  wishes  to  use  as  limiting  criteria  in  the  Search 
Jirgtiment.  The  tool  as  described  is  very  general  purpose,  but  this  may  not  always  be  the 
optimal  approach  -  see  "Operation  Template  Editor"  below. 

•  Search  Scope.  The  Search  operation  is  the  most  powerful  interrogation  operation  available 
to  the  user,  but  it  is  £ilso  the  most  resource  intensive  and  often  the  most  time-consimiing.  The 
provision  of  a  tool  to  enable  the  user  easily  to  limit  the  scope  of  the  seeirch  Cein  help  to  optimize 
resource  usage  as  well  as  to  get  residts  back  to  the  user  more  quickly.  One  method  of  achieving 
this  might  be  to  provide  a  mechanism  enabling  the  user  to  compose  a  single  Search  request 
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and  have  it  directed  at  multiple,  small,  naming  contexts  where  the  user  feels  the  likelihood  of 
a  hit  will  be  greatest.  Thus,  for  example,  if  a  user  wishes  to  locate  an  individual  who  works 
in  the  federal  government,  and  is  fairly  certidn  that  the  person  in  question  works  for  the 
United  States  Department  of  Agriculture  (USDA)  or  the  Environmental  Protection  Agency 
(EPA),  the  tool  would  send  off  two  essentially  identical  requests  to  search  the  USDA  and 
EPA  domains,  instead  of  searching  the  whole  of  the  U.S.  Government  domain.  This  produces 
a  much  quicker  response  time  at  little  extra  effort  expenditure  on  the  pait  of  the  user.  While 
this  example  might  seem  trite,  the  power  of  such  a  tool  woiild  be  much  more  evident  if 
the  number  of  agencies  concerned  were  larger,  or  government  contractor  orgtinizations  were 
involved,  or  the  search  scope  in  each  instance  were  more  restricted  (for  exftmple  "personnel 
office"). 

•  Entry  Modification  Editor.  Whenever  the  user  indicates  an  intention  to  modify  an  entry, 
the  interface  might  automatically  retrieve  the  contents  of  the  entry  using  a  Read  operation, 
and  display  them  in  an  editable  window.  The  user  can  then  make  any  desired  modifications 
to  the  contents  of  the  entry  with  the  editor,  the  modifications  fire  automaticfiUy  converted 
into  a  Modify  Entry  request  and  shipped  off  to  the  Directory. 

•  Operation  Template  Editor.  In  many  situations,  exposure  of  the  DUA  user  to  the  fuU 
potentied  of  a  DUA  is  neither  necessary  nor  desirable.  In  such  cases,  it  may  be  desirable 
to  provide  the  user  with  a  custom  DUA  which  provides  operation  templates;  for  exfimple,  a 
template  which  offers  a  name  seairch  facility,  such  as  that  shown  in  Figure  3.4,  in  which  the 


Name  Search 


Name:.  H9J?^s  

Organization:  .P®pt : . .9.^ .  C??!!i?erce 
Locality:..*.   


Results: . .  .H.qbbs ,  Frank  B . 

Hobbs ,  Thomas  G . 


Figure  3.4:  An  example  of  an  operation  template  for  a  Name-based  Search  operation. 

user  needs  to  supply  only  a  common  name  and  possibly  one  or  more  of  a  restricted  nimiber 
of  other  paxameters,  such  as  organization  naime,  locality,  an.d  so  on.  The  provision  of  such 
simplified  operation  templates  will  be  tailored  to  the  needs  of  the  particular  orgsmization, 
and  templates  will  be  designed  to  accommodate  those  operations  most  commonly  rtqiured  by 
users.  In  psirticular,  such  templates  can  isolate  the  user  completely  from  exposure  to  Directory 
Distinguished  Names^'^  by  relying  heavily  on  the  Search  operation  to  locate  entries  and  using 

See  Section  2.5  for  moie  on  Distinguished  Names. 
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the  information  contained  in  the  SesiTch  result  as  input  to  Read  operations  if  the  need  arises, 
without  the  need  for  user  input.  The  provision  of  a  tool  to  enable  the  creation  of  such 
operation  templates  for  the  DUA  is  highly  desirable. 


3.2.2.6  Inforxnativeness 


Surrounding  the  core  functionality  of  the  interface,  which  enables  the  user  to  gfdn  quick  and  efhcient 
access  to  Directory  information,  should  be  a  large  catalog  of  information  about  the  interface  itself, 
it's  functionality,  the  Directory  attributes,  object  classes,  and  operations  that  it  supports,  find  so 
on.  Ideally,  a  naive  user  will  be  able  to  start  the  package  up  and  obtsdn  meaningful  information 
from  the  Directory  with  a  minimum  of  difficulty  and  without  cause  to  move  away  from  his/her 
workstation.  Some  features  to  look  for  in  this  regjird  «ire  listed  below: 


•  On-line  Help.  Extensive  on-line  help  should  be  available.  The  help  facility  should  give 
clear  and  concise  explanations  of  any  item  pointed  to  on  the  screen,  in  addition  to  offering 
a  writable  text  window  for  the  entry  of  help  requests.  The  help  facility  should  have  the 
capability  to  address  topics  pertedning  to  the  user  interface  itself,  such  that  its  operation 
is  fuUy  explainable,  as  well  as  to  address  X.500  topics  insofar  as  they  pertain  to  the  user 
interface  (for  exeimple;  attributes,  operations,  object  classes,  etc.). 

•  Explanation  of  Errors.  The  interface  should  have  the  capability  to  present  clear,  detailed, 
plain  Icinguage  explanations  of  any  errors  that  occtir  during  operation,  including  errors  related 

/  \ 

I    Enquiry  Failed  J 


Your  request  to  READ  the  entry  with  Common  Name 
"Hobbs,  Frank  B."  was  unsuccessful  because  you 
do  not  have  the  necessary  security  priveleges  to 
access  the  contents  of  the  entry. 

For  more  information  about  security  procedures  and 
local  security  policy  select  here:  jcoNmuE) 


\  } 

Figure  3.5:  An  example  of  a  plain  language  error  notification. 

to  the  Directory,  communications  or  interface.  The  provision  of  multiple-level,  branched, 
menu- driven  explemations  would  be  a  great  asset,  providing  terse,  high-level  explanations  for 
expert  users  as  well  as  detailed  explanations  for  the  novice  user,  and  a  range  in  between. 
Figure  3.5  shows  an  example  of  such  an  error  notification. 
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3.2.3    Directory  System  Agents 


As  with  DUAs,  the  range  of  non-standard  features  which  might  be  associated  with  a  DSA  product 
is  likely  to  be  very  large,  and  we  can  only  hope  to  give  some  general  pointers  as  to  what  the  user, 
or  more  likely,  the  system  administrator,  should  investigate. 

There  are  a  ntunber  of  broad  subject  categories  to  address  when  discussing  the  functioneJity  of 
DSAs,  which  may  be  summarized  as  follows:  Configurability  of  the  product  ensures  that  the  operator 
can  tailor  the  operation  of  the  package  to  best  fit  the  administrative  policy  for  the  Directory  which 
has  been  set  up  by  his/her  organization;  Operator  Tools  enable  the  operator  to  administer  the 
DSA  as  efficiently  as  possible;  An  SQL  or  other  interface  to  a  conventional  Database  Management 
System  (DBMS)  means  that  the  DSA  package  cein  operate  in  combination  with  a  regular  DBMS 
package. 

3.2.3.1  Configurability 

As  with  DUAs,  all  aspects  of  the  operation  of  the  DSA  should  be  as  fully  configurable  as  possible. 
For  each  feature,  a  clear,  easy-to-use  tool  should  exist,  again  preferably  windows-based,  to  enable 
the  operator /administrator  to  configrire  the  DSA  in  accordsince  with  policy  requirements  quickly 
and  with  as  few  errors  or  problems  as  possible,  or  there  should  be  cleax  information  available  as 
to  which  files  should  be  edited  in  order  to  bring  about  the  desired  configuration.  Extensive  help 
facilities  should  also  exist  (see  sec.  3.2.2.6). 

A  selection  of  aspects  of  DSA  operation  for  which  configurability  is  crucial  is  listed  below: 

•  Security  Configiuration.  The  X.500  (1994)  specifies  powerfiil  sectarity  features  which 
allow  strong  authentication  using  public  key  cryptosystems  and  access  control  to  information 
on  various  levels,  including  Administrative  Area,  Entry,  Attribute  and  Attribute  Viilue.  All 
aspects  of  £in  orgainization's  security  policy  shoidd  be  easily  configurable  on  each  of  its  DSAs, 
either  through  the  use  of  a  specialized  tool  or  through  simple  editing  of  plain  text  configuration 
fUes.34 

•  Schema  Configuration.  The  DSA  package  should  enable  full  implementation  of  the  orga- 
nization's X.500  schema,  allowing  for  the  definition  of  non-Standeird  attribute  types,  object 
classes,  matching  rules,  DIT  content  rules,  DIT  structure  rules  and  name  forms,"*^  as  well  as 
supporting  those  defined  in  the  Standfird,  Reference  [1]. 

3.2.3.2  Operator  Tools 

Each  DSA  is  a  node  which  holds  a  part  of  the  global  Directory  Information  Base.  As  such,  it  should 
be  regarded  as  an  essential  information  server  and  assigned  a  commensurate  nimiber  of  staff^^  to 

"see  Section  2.8  and  Reference  [10]  for  discussions  of  X.500  Security  features. 

** Since  these  files  contain  detailed  information  on  security  policy,  they  should  themselves  be  carefully  protected. 
''See  Section  2.5  and  Reference  [3]  for  discussions  of  X.500  Schema  elements. 

"Clearly  this  number  is  at  the  discretion  of  the  owner  organization  and  depends  on  the  scale  and  operational  status 
of  the  server  in  question.  A  small  academic  server  may  require  a  part  time  individual  {lom  time  to  time,  while  a  DSA 
holding  a  large  part  of  a  highly  active  corporate  or  governmental  DIB  may  require  round-the-clock  supervision. 
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administer  secxirity  and  schema  policies,  to  set  up  and  monitor  replication  agreements,  to  load  the 
data  initially,  making  sure  it  complies  with  schema  and  security  requirements,  to  perform  backup 
and  restoration  of  Directory  data,  and  generally  to  supervise  the  DSA's  operation,  to  respond  to 
any  problems  that  might  arise  and  provide  general  user  services. 

In  order  to  assist  the  DSA  administrator(s)  in  the  efficient  performance  of  these  tasks,  the  DSA 
package  should  provide  a  collection  of  clearly  documented  tools  enabling  the  administrator  to  attend 
to  the  tasks  with  a  minimum  of  effort.  Again,  it  is  envisioned  that  a  windows-based  interface  will 
be  most  suitable  at  this  time.  Some  examples  of  administrator  functions  and  how  they  might  be 
carried  out  are  included  below: 

•  Schema  Design.  A  large  scale  X.500  deployment,  either  within  an  orgfinization  or  spanning 
multiple  organizations,  will  be  made  up  of  a  number  of  Directory  Management  Domains, 
DIT  Domains  and  Administrative  Areas,  each  with  its  own  policies  on  schema,  security  and 
administration.  The  DSA  operator's  toolkit  should  contain  tools  to  simplify  the  definition  of 
new  schema  elements  by;  for  exeimple,  allowing  the  operator  to  specify  an  existing  schema 
element  from  which  a  new  schema  element  is  to  be  derived  and  allowing  her/him  to  add  or 
subtract  elements,  name  the  new  element,  modify  the  inheritfince  hierarchies  to  which  the 
element  belongs and  so  on,  in  an  editable  window. 

•  Administration  and  Maintenance.  As  with  any  database,  the  DSA  package  requires  a  set 
of  tools  to  carry  out  fundamental  maintenance  functions,  such  as  backing  up  £ind  restoring  the 
DIB  as  necesseiry,  printing  out  portions  of  the  DIB,  reviewing  access  control  policy,  cleaning 
up  inactive  DIB  sections,  and  so  on.  However,  because  the  Directory  is  distributed,  other 
administrative  functions  are  also  required,  such  as  the  configuration  of  knowledge  references,^^ 
management  of  operational  bindings  (including  shadowing  agreements and  so  on. 

•  Bulk  Data  Load.  When  the  DIB  segment  held  by  a  given  DSA  is  initially  populated  or 
when  the  DSA  needs  to  be  reloaded  from  back-up  for  some  reason  (equipment  failure,  security 
breach  or  other  imforeseen  circumstance),  a  method  of  loading,  the  entire  DIB  segment  quickly 
from  a  bulk  data  file  may  be  required.  The  Standard,  Reference  [1],  does  not  specify  how 
this  should  be  done,  so  it  is  left  to  the  vendor.  At  the  very  least,  the  DSA  package  should 
be  equipped  with  some  facility  which  will  take  bulk  data  from  some  sort  of  file  and  load  it 
into  the  DIB  in  a  format  suitable  for  the  DSA  to  read.  The  tool  might  filso  contain  functions 
enabling  the  operator  to  selectively  load  or  reload  parts  of  the  database,  and  might  present  the 
operator  with  an  easy-to-interpret  interface,  perhaps  giving  a  schematic  of  the  DIT  contained 
in  the  back-up  file,  allowing  the  operator  to  select  which  sections  to  load  by  clicking  on  em 
entry  in  the  diagram. 

For  initial  population  of  the  DIB,  a  Directory  Synchronization  package  will  almost  certainly 
be  required.  Such  a  device  enables  the  DIB  administrator  to  create  a  mapping  utility  to  map 
from  any  existing  Directory  facility  into  a  format  suitable  for  the  DSA,  and  thus  facilitates 
the  transition  from  a  pre-existing,  proprietary  directory  or  database  facility  to  one  based  on 
r  X.500. 

The  actueil  mechanism  of  getting  the  data  into  the  DIB  may  be  proprietary/internal,  in  which 
case  the  DIB  will  be  populated  from  a  back-up  file  on  the  same  system  as  the  DSA  in  a  vendor- 
specific  maimer;  or  the  mechimism  may  use  a  specialized  DUA  to  popidate  the  DIB  using 

'^See  Sections  2.4  and  2.3  for  discussions  of  inheritance  of  characteristics  in  schema  elements. 
"See  Section  2.5  for  moie  information  on  knowledge  references. 
'^See  Section  2.10  for  information  on  shadowing  agreements. 
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multiple  X.500  Add  Entry  operations.*^  The  proprietary  method  is  likely  to  be  quickest, 
particxilarly  if  the  DSA  and  the  back-up  are  collocated  on  the  same  machine.  The  use  of  a 
specialized  DUA,  however,  permits  the  loading  of  the  DSA  across  a  network,  £ind  thus  the 
maintenance  of  a  back-up  database  at  a  separate  location  from  the  Directory  System  Agent. 
It  should  be  borne  in  mind,  though,  that  if  the  DIB  is  large,  such  an  operation  may  have  a 
significant  impact  on  network  performance  for  other  network  users. 

•  Activity  Reporting  Package.  It  is  highly  desirable  for  the  DSA  package  to  include  an 
activity  reporting  feature  to  enable  the  operator  to  easily  review  vfirious  usage  statistics, 
such  as  frequency  of  contact  by  other  DSAs  or  by  DUAs,  frequency  of  access  to  various  parts 
of  the  DIT,  security  warnings,  and  so  on.  The  ability  to  display  such  information  in  a  readily 
interpretable  form  (e.g.,  graphiczdly)  is  highly  desirable.  Access  to  this  information  can  assist 
the  DSA  operator  in  configuring  his/her  DSA  to  nm  most  efficiently  (e.g.,  by  medntedning 
most-accessed  information  in  core  memory  instead  of  on  disc)  snd  can  fiid  in  the  management 
of  operational  bindings  and  replication  agreements  between  Directory  System  Agents. 


3.2.3.3    Relational  Database  Management  System  Interface 


One  approach  to  the  database  management  aspects  of  DSAs  has  been  to  implement  the  DSA  as 
a  front-end  package  to  £in  existing  Database  Management  System  (DBMS)  or  a  Relational  DBMS 
(RDBMS).  Typically,  fin  RDBMS  using  Standard  Query  Language  (SQL)  is  most  suitable  for  this 
tjrpe  of  product,  since  the  DSA  product  can  then  be  run  as  an  application  using  a  variety  of 
RDBMS  products  supporting  the  Structured  Query  Language.*^  Figure  3.6  shows  a  schematic 
representation  of  such  an  firreingement. 


DSA  Front-End 


(SQL  Interface) 


RDBMS 


Database 


Figure  3.6:  Schematic  representation  of  a  DSA  front-ending  to  a  conventional  Relational  Database 
Management  System. 

The  DSA  front-end  adapts  the  relationail  structure  of  the  RDBMS  to  mimic  the  hierarchiceJ  struc- 
ture of  the  Directory  Information  Tree.  The  operator  uses  the  management  tools  associated  with 
the  RDBMS  to  manage  the  DIB,  edthough  some  activity  statistics  will  still  need  to  be  provided  by 
the  DSA  application  (e.g.,  frequency  of  contact  with  other  DSAs,  security  warnings,  etc.). 

*°See  Section  2.6  for  information  on  the  X.500  Add  Entry  operation. 
*^At  least  in  theory! 
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Such  a  product  configuration  is  desirable  because  it  promotes  £in  open  jirchitectiire,  allowing  the 
customer  to  choose  between  DSA  and  DBMS  applications  which  best  suit  her/his  needs.  In  partic- 
ular, the  customer  may  purchase  a  DSA  application  to  match  an  installed  DBMS  package  without 
duplicating  functioniJity. 
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Chapter  4 


Performance  Evaluation  of  X.500 
Products 

This  chapter  provides  gtiideliaes  for  the  evaluation  of  the  perform£ince  of  an  X.500  product.  Per- 
formance in  terms  of  the  Directory  is  assessed  from  two  perspectives,  and  a  testing  methodology 
for  measuring  aspects  of  X.500  product  performance  is  outlined. 

4.1    Aspects  of  Directory  Product  Performance 

Performsmce  in  terms  of  the  Directory  can  be  viewed  from  two  perspectives,  which  might  be  termed 
hard  and  soft. 

The  hard  aspects  of  Directory  performance  are  those  quaintities  which  cam  readily  be  measiired, 
such  as  the  time  required  by  a  DSA  to  process  a  given  operation  under  controlled  or  laboratory 
conditions.  These  measurements  can  be  used  as  indicators  of  how  the  DSA  might  perform  under  real 
world  conditions  (though  the  compeirative  complexity  and  impredictability  of  a  real  world  situation 
preclude  the  use  of  these  measurements  as  predictors).  Measurements  of  hard  performance  axe 
couched  in  terms  of  tasks  completed  per  unit  time,  i.e.,  the  unit  of  measurement  is  essentially 
temporal. 

The  soft  aspects  of  Directory  performance  refer  to  more  nebulous,  less  readily  measurable  properties 
of  the  product,  which  contribute  indirectly  to  the  hard  performance  of  any  given  DSA,  or  may 
contribute  to  the  performance  of  the  Directory  as  a  whole,  but  not  necessarily  to  that  of  any 
particulsir  DSA  or  operation.  Such  qualities  might  include  the  "effectiveness"  of  a  user  interface 
and  the  "intelligence"  of  a  Directory  System  Agent. 

Note:  In  the  sections  that  follow,  whenever  a  measurement  is  specified,  the  implicit  assumption  is 
that  the  specified  operation  can  be  completed  (i.e.,  the  target  entry  exists  and  contains  the  necessary 
information)  such  that  the  only  subject  at  issue  is  the  time  taken  to  complete  an  operation  which 
is  known  in  advance  to  be  possible.  Also,  these  measrirements  are  designed  for  use  under  controlled 
conditions.  CompMisons  between  the  products  of  different  vendors  thus  rely  on  differences  in 
response  times  for  a  predefined  operation  on  a  predefined  DIT,  held  in  different  systems  of  the 
same  type. 
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4.1.1    Hard  Aspects  of  Directory  Performance 


These  are  aspects  of  X.500  product  performance  that  can  easily  be  measured  in  terms  of  the  amount 
of  time  required  for  completion. 


4.1.1.1    Directory  User  Agent  User  Interfaces 

•  Operation  Request  Processing  Time.  For  each  operation,  the  time  taken  between  the 
user's  indication  that  he/she  is  ready  to  send  a  predefined  (and  syntactically  correct)  re- 
quest (usually  by  hitting  the  Return  key  or  selecting  the  requisite  button  in  a  windowing 
environment)  and  the  subsequent  output  of  a  DAP  operation  by  the  Directory  User  Agent. 

•  Error  Detection.  The  time  taken  for  the  DUA  to  report  the  presence  of  a  predefined  set 
of  errors  inserted  into  an  operation  request. 

•  Operation  Response  Processing  Time.  For  each  operation,  the  time  taken  between  the 
receipt  of  a  predefined  operation  response  over  the  DAP  by  the  DUA  find  the  display  of  the 

i    encoded  information  on  the  user's  display  device.*"^ 

•  Operation  Error /Referral  Processing  Time.  For  each^^  operation,  the  time  taken  be- 
tween the  receipt  of  «in  operation  error  or  referral  over  the  DAP  by  the  DUA  find  the  display 
of  the  encoded  information  on  the  user's  display  device. 

•  Automatic  Processing  of  Referrals.  When  a  DUA  has  the  capability  to  automatically 
process  DAP  referrals,  then  for  a  predefined  set  of  referrals,  the  time  between  the  receipt  of 
a  referral  over  the  DAP  find  the  output  of  a  new  operation  request  over  the  Directory  Access 
Protocol. 

•  Startup  Time.  The  time  tfiken  between  the  invocation  of  the  DUA  progrfim  and  the  avail- 
ability of  the  DUA  services  to  the  user. 


4.1.1.2    Directory  User  Agent  Programmatic  Interfaces 


Since  the  DUA  Programmatic  Interface  usufilly  forms  an  integrfJ  part  of  the  DUA  User  Interface, 
in  that  it  provides  the  protocol-related  services  of  the  DUA,  some  of  the  measurements  given 
for  the  User  Interface  apply  equally  to  the  Progrfimmatic  Interface  or  Application  Programming 
Interface.  The  comments  related  to  Error  Detection  find  Automatic  Processing  of  Referrals 
fJso  apply  to  the  Application  Programming  Interface.  Two  additional  measurements  of  note  for 
the  API  are  the  time  between  invocation  of  the  API  find  output  of  a  DAP  operation,  for  each  DAP 
operation;  find,  again  for  each  operation,  the  time  between  receipt  of  a  DAP  result  or  error  find  the 
presentation  of  this  information  to  the  invoking  entity. 

a  normal  working  environment  it  is  not  necessarily  desirable  to  display  the  information  immediately  as  the 
user's  display  may  already  be  in  use,  but  for  our  purposes  here  the  time  to  display  is  an  appropriate  measurement. 
*'0r  a  representative. 


58 


4.1. l.S    Directory  System  Agents 

•  The  DAP  Resolution  of  Request.  For  each  operation,  the  time  between  the  receipt  of  a 
DAP  request  and  the  output  of  a  DAP  response.  In  this  instance,  the  DSA  is  known  to  hold 
the  target  entry  of  the  operation  request  and  the  ttirget  entry  is  known  to  hold  the  requested 
information. 

•  The  DSP  Resolution  of  Request.  For  each  operation,  the  time  between  the  receipt  of  a 
DSP  request  and  the  output  of  a  DSP  response.  In  this  instzince,  the  DSA  is  known  to  hold 
the  target  entry  of  the  operation  request  and  the  target  entry  is  known  to  hold  the  requested 
information. 

•  The  DAP  and  DSP  Production  of  Referral.  For  each  operation,  the  time  between  the 
receipt  of  a  DAP  or  DSP  request  and  the  output  of  a  DAP  or  DSP  referral.** 

•  The  DAP  and  DSP  Display  of  Error.  For  each  operation,  the  time  between  the  receipt 
of  a  DAP  or  DSP  request  eind  the  output  of  a  DAP  or  DSP  error.  For  each  operation,  time 
to  display  each  possible  error  should  be  measured.  Clearly,  this  measurement  requires  the 
deliberate  submission  of  erroneous  operation  requests.  The  standard  lists  which  errors  are 
permissible  for  each  operation  (see  Reference  [4]). 

•  The  DAP  or  DSP  Chaining  of  Request.  For  each  operation,  the  time  between  the 
receipt  of  an  operation  request  which  the  DSA  is  unable  to  satisfy  and  the  output  of  a  single 
chained  operation  request. 

•  Chaining  of  Requests  -  Search  Request  Decomposition.  When  Seairch  Request 
Decomposition*^  occurs  as  part  of  the  processing  of  a  Search  operation,  two  measurements 
are  of  interest: 

-  The  time  between  the  receipt  of  a  Search  operation  request  APDU  (DAP  or  DSP) 
and  the  output  of  the  fined  Secirch  request  operation  APDU  resulting  from  the  request 
decomposition,  and 

-  The  time  between  the  receipt  of  the  fined  operation  result,  error  or  referral  APDU  re- 
sulting from  the  requests  issued  as  a  result  of  request  decomposition  and  the  output  of 
a  result,  error  or  referral  APDU  to  the  original  requestor. 

The  former  measures  how  quickly  the  DSA  can  parse  a  Search  request  and  forward  the 
components  to  the  appropriate  DSAs,  while  the  latter  measures  how  quickly  the  results  can 
be  reassembled  eind  forweirded  to  the  original  requestor. 

•  Structure  of  Directory  Information  Tree.  Some  DSA  products  are  more  sensitive  to 
the  structure  of  the  DIT  than  others.  Some  perform  better  with  a  broad,  flat  DIT  (few  levels 
in  the  hierarchy,  but  many  entries  at  each  level)  while  others  excel  within  the  confines  of  a 
deep,  narrow  tree  (many  levels  in  the  hierarchy  with  comparatively  few  entries  at  each  level). 

**Tlii8  measuiement  could  be  split  into  a  set  of  measuiements,  depending  on  the  type  of  knowledge  reference  used 
to  generate  the  referral. 

^'This  measurenaent  could  be  split  into  a  set  of  measurements,  depending  on  the  type  of  reference  used  to  generate 
the  chained  request. 

*'l.e.,  the  breaking  up  of  a  Search  operation  request  into  multiple  domain-specific  requests  and  the  forwarding 
of  these  requests  to  multiple  subordinate  Directory  System  Agents.  A  Search  request  ia  thus  propagated  down  the 
Directory  Information  Tree.  See  Reference  [4]  and  Reference  [5]  for  more  detaUs. 
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A  product  can  be  evaluated  for  performance  in  this  regtird  by  selecting  a  set  of  operations 
and  ninning  them  against  DSAs  set  up  under  the  two  configurations. 


•  Performance  Under  Load  Conditions.  The  best  test  of  a  DSA  product  under  load 
conditions  is  to  see  it  run  in  an  operational  environment,  but  in  such  environments  it  is 
impossible  to  st£ind£irdize  measurements  of  the  performance  of  one  product  against  another, 
though  the  experience  of  the  staff  involved  with  the  installation  is  invaluable.  In  order  to  test 
the  performance  of  a  DSA  product  under  load  conditions  (i.e.,  where  multiple  operations  are 
being  processed  simultaneously)  in  a  standard  way,  a  DUA  should  be  set  up  to  fire  out  multiple 
operation  requests  at  a  DSA  or  collection  of  Directory  System  Agents.  The  operation  requests 
may  come  from  a  batch  fUe  and  be  pre-encoded,  in  order  to  speed  delivery.  The  operations 
should  be  ttiilored  towards  the  configuration  being  tested.  The  measure  of  performance  here 
again  is  time  -  the  speed  with  which  the  DSA  configuration  resolves  the  set  of  simultfineous 
requests  it  receives. 

•  Steurt-up  Time.  The  length  of  time  after  which  a  DSA  becomes  available  following  a  system 
failure,  re-initialization,  madntenance,  etc. 

4.1.2    Soft  Aspects  of  Directory  Performance 

These  are  features  or  qualities  of  a  Directory  product  which,  while  not  as  easily  measurable  as 
the  hard  aspects  described  above,  may  contribute  significantly  to  the  speed  and  efficiency  of  the 
Directory  and  hence  to  the  productivity  of  its  users. 

•  Efficiency  of  User  Interface.  The  notion  of  efficiency  is  difficult  to  define  Ln  terms  of  a 
Directory  user  interface,  but  if  we  take  a  holistic  approach,  we  are  able  to  derive  a  measurable 
qujintity  from  the  definition.  Thus,  we  define  the  efficiency  of  the  user  interface  to  be  the 
time  between  the  initial  formtdation  in  the  user's  mind  of  what  information  to  seek,  and  the 
user's  comprehension  of  the  result  of  the  corresponding  operation.^^  This  includes  the  time 
taken  to  bring  up  and  fill  out  the  most  appropriate  interface  screen,  as  well  as  the  time  taken 
for  retries  if  the  results  returned  indicate  that  an  inappropriate  request  was  sent,  and  so  on. 

Since  the  user  interface  is  the  mediator  between  the  user  eind  the  Directory,  it  foUows  that 
the  more  qmckly  the  user  can  process  an  information  request  through  the  DUA,  the  more 
efficient  the  user  interface  is. 

•  Intelligent  Featiures.  These  aie  features  whose  presence  is  like  to  enheince  the  efficiency 
of  information  management  in  the  Directory.  They  aire  not  directly  measurable,  but  their 
presence  or  absence  may  be  noted. 

-  Automatic  Shadowing.  Where  possible,  DSAs  can  automatically  set  up  shadowing  agree- 
ments if  heavy  use  of  a  subtree  is  detected.  By  shadowing  the  information,  the  consumer 
DSA  reduces  access  time  and  network  congestion. 

—  Automatic  Cross- Referencing.  If  heavy  use  of  a  remote  DSA  for  which  no  knowledge 
reference  exists  is  detected,  a  DSA  might  automatically  add  a  cross  reference  to  the 
remote  DSA  to  its  knowledge  base. 

^^This  definition  assumes  that  all  othei  factors,  such  as  DUA  operation  processing  time,  DSA  operation  processing 
time  and  the  time  for  the  request  and  result  APDUs  to  travel  between  the  DUA  and  DSA,  are  constant.  If  they  are 
not,  then  they  must  be  factored  out. 


60 


—  Caching  of  an  Entry  by  a  Directory  User  Agent.  If  a  DUA  detects  that  heavy  use  is 
being  made  of  a  psirticular  entry,  it  may  automatically  issue  a  Read  request,  cache  the 
result,  and  use  the  cached  information  to  satisfy  further  queries.  In  this  instemce,  the 
benefits  in  terms  of  access  time  need  to  be  weighed  agjiinst  the  loss  of  confidence  in  the 
accuracy  of  the  information,  since  no  standard  replication  agreement  exists.  This  option 
should  be  subject  to  pre-authorization  by  the  user. 

—  Automatic  Resolution  of  Referrals.  This  is  a  stfindard  feature  which  saves  the  user  from 
the  task  of  re- initiating  an  operation  if  it  was  not  possible  to  chain  it  within  the  Directory. 

—  Shielding  User  from  Distinguished  Names.  To  increase  the  efficiency  of  the  user  interface, 
as  discussed  above,  the  user  should  be  shielded  from  Directory  Distinguished  Naimes. 
This  can  be  done  through  use  of  the  Search  and  List  operations,  showing  only  the  Relative 
Distinguished  Names  and  «Jlowing  the  user  to  select  on  them  in  order  to  initiate  other 
operations.  In  this  way,  the  Distinguished  Names  of  entries  fire  held  purely  internally  to 
the  user  interface. 

4.2    Performance  Evaluation  Methodology 

The  Performance  EvcJuation  Methodology  for  X.500  Directory  products  will  be  detaiiled  in  a  fu- 
ture publication  which  will  describe  the  methodology  and  report  on  its  practicfil  application  in  a 
laboratory  environment. 

In  broad  terms,  as  discussed  above,  the  evaluation  of  a  product  will  involve  the  incorporation  of 
timers  around  the  softwfire  units  comprising  the  Directory  product  and  the  measurement  of  the 
time  taken  to  perform  stfindard  tasks  under  controlled  conditions. 
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other  special  publications  appropriate  to  this  grouping  such  as  wall  charts,  pocket  cards,  and  bibliographies. 

National  Standard  Reference  Data  Series — Provides  quantitative  data  on  the  physical  and  chemical 
properties  of  materials,  compiled  from  the  world's  literature  and  critically  evaluated.  Developed  under  a 
worldwide  program  coordinated  by  NIST  under  the  authority  of  the  National  Standard  Data  Act  (Public 
Law  90-396).  NOTE:  The  Journal  of  Physical  and  Chemical  Reference  Data  (JPCRD)  is  published 
bimonthly  for  NIST  by  the  American  Chemical  Society  (ACS)  and  the  American  Institute  of  Physics  (AIP). 
Subscriptions,  reprints,  and  supplements  are  available  from  ACS,  1155  Sixteenth  St.,  NW,  Washington,  DC 
20056. 

Building  Science  Series — Disseminates  technical  information  developed  at  the  Institute  on  building 
materials,  components,  systems,  and  whole  structures.  The  series  presents  research  results,  test  methods,  and 
performance  criteria  related  to  the  structural  and  environmental  functions  and  the  durability  and  safety 
characteristics  of  building  elements  and  systems. 

Technical  Notes — Studies  or  reports  which  are  complete  in  themselves  but  restrictive  in  their  treatment  of 
a  subject.  Analogous  to  monographs  but  not  so  comprehensive  in  scope  or  definitive  in  treatment  of  the 
subject  area.  Often  serve  as  a  vehicle  for  final  reports  of  work  performed  at  NIST  under  the  sponsorship  of 
other  government  agencies. 

Voluntary  Product  Standards — Developed  under  procedures  published  by  the  Department  of  Commerce 
in  Part  10,  Title  15,  of  the  Code  of  Federal  Regulations.  The  standards  establish  nationally  recognized 
requirements  for  products,  and  provide  all  concerned  interests  with  a  basis  for  common  understanding  of 
the  characteristics  of  the  products.  NIST  administers  this  program  in  support  of  the  efforts  of  private-sector 
standardizing  organizations. 

Order  the  following  NIST  publications — FIPS  and  NISTIRs—from  the  National  Technical  Information 
Service,  Springfield,  VA  22161. 

Federal  Information  Processing  Standards  Publications  (TIPS  PUB) — Publications  in  this  series 
collectively  constitute  the  Federal  Information  Processing  Standards  Register.  The  Register  serves  as  the 
official  source  of  information  in  the  Federal  Government  regarding  standards  issued  by  NIST  pursuant  to 
the  Federal  Property  and  Administrative  Services  Act  of  1949  as  amended.  Public  Law  89-306  (79  Stat. 
1127),  and  as  implemented  by  Executive  Order  11717  (38  FR  12315,  dated  May  11,  1973)  and  Part  6  of 
Title  15  CFR  (Code  of  Federal  Regulations). 

NIST  Interagency  Reports  (NISTIR) — A  special  series  of  interim  or  final  reports  on  work  performed  by 
NIST  for  outside  sponsors  (both  government  and  nongovernment).  In  general,  initial  distribution  is  handled 
by  the  sponsor;  public  distribution  is  by  the  National  Technical  Information  Service,  Springfield,  VA  22161, 
in  paper  copy  or  microfiche  form. 
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